[Snippet] Type

[Nestharus]

This resource has moved here.

--

gone

 

[Almia]

private Type parent

What is the difference between thistype and Type?

 

[Nestharus]

No difference =)

 

[Almia]

is it just you are lazy to type thistype or coz Type is shorter than thistype

 

[Nestharus]

No, made it explicit for easier to understand code

 

[Magtheridon96]

Approved.

 

[Almia]

I dun get this.
What is this for?

 

[pred1980]

yeah, i dont see any use!

 

[Nestharus]

When ya'll get better at coding, you'll see its use. Until then, debating its use is pointless =).

 

[Almia]

You got a point.
I think this shall result the same like rcon, sbox, ltable.

 

[pred1980]

When ya'll get better at coding, you'll see its use. Until then, debating its use is pointless =).

LOL ? It was just a question and after your answer i'm still at the same point to ask you: What is this for?

 

[Nestharus]

There is no answer to your question, lol. It is for anything you want to use it for, that's the answer.

I told you, that question is pointless. When you get enough experience and see a use for it, you've found your use. I could list off 50 examples, but I'm not going to, that'd waste everyone's time.

 

[Bannar]

Nes, since many ppl got Table already implemented in thier maps - meaby add Table version as optional. Just a suggestion tho.

 

[Nestharus]

It doesn't use Table for a reason ; ). It creates a lot of hashtable entries.

 

[Magtheridon96]

I'll give an example.

Imagine a system with custom damage types.

You can use this to make one damage extend others. You'll have a damage type tree that you can work with and this will allow you to avoid a ton of flags for each damage type

// Base types
globals
    Type DAMAGE_TYPE_DPS
    Type DAMAGE_TYPE_SLOW
endglobals

globals
    Type DAMAGE_TYPE_FIRE
    Type DAMAGE_TYPE_POISON

    Type DAMAGE_TYPE_ICE
    Type DAMAGE_TYPE_FROST
    Type DAMAGE_TYPE_MUCK
endglobals

private module Init
    private static method onInit takes nothing returns nothing
        set DAMAGE_TYPE_DPS = Type.create(0)
        set DAMAGE_TYPE_SLOW = Type.create(0)

        set DAMAGE_TYPE_FIRE = Type.create(DAMAGE_TYPE_DPS)
        set DAMAGE_TYPE_POISON = Type.create(DAMAGE_TYPE_DPS)

        set DAMAGE_TYPE_ICE = Type.create(DAMAGE_TYPE_SLOW)
        set DAMAGE_TYPE_FROST = Type.create(DAMAGE_TYPE_SLOW)
        set DAMAGE_TYPE_MUCK = Type.create(DAMAGE_TYPE_SLOW)
    endmethod
endmodule

private struct InitS extends array
    implement Init
endstruct

This is one example of the many uses this has
Imagine being able to define code for each base damage type.
The extending damage types would instantly have that code work for them and they would also add to it ^_^.
DAMAGE_TYPE_DPS would deal damage over time. DAMAGE_TYPE_FIRE would do what DAMAGE_TYPE_DPS does, then it would add a fire special effect for example

 

[Zwiebelchen]

You always amaze me with making the impossible possible, lol.

I'm curious ... how does this work? I try to figure it out, but I can't get a clue because I don't know how structs in vJASS actually compile.

 

[Magtheridon96]

Structs compile like this:

- Static methods become regular functions
- Static variables become global variables
- Methods become functions that take an integer called this
- Variables become global array variables that use this as an index.
- Static method operators and method operators are treated like static and non-static methods.
- Modules just CnP the code they have inside them in the struct before everything compiles. Thankfully, Vexorian assured that a module will only be implemented once per struct. (No duplicate code, wee /o/)
- If the struct does not extend an array, you'll have generated allocate() and deallocate(integer) methods. Allocate compiles to a function that returns a unique integer and deallocate will compile to a function that takes an integer representing the instance to be deallocated and returns nothing.
- When inheritance comes into play, it's about either sharing functions or copying them.

That's all I can come up with on the spot. I might be wrong about something and I might have left something out. (I know I left out delegates and interfaces for one)

 

[Zwiebelchen]

Structs compile like this:

- Static methods become regular functions
- Static variables become global variables
- Methods become functions that take an integer called this
- Variables become global array variables that use this as an index.
- Static method operators and method operators are treated like static and non-static methods.
- Modules just CnP the code they have inside them in the struct before everything compiles. Thankfully, Vexorian assured that a module will only be implemented once per struct. (No duplicate code, wee /o/)
- If the struct does not extend an array, you'll have generated allocate() and deallocate(integer) methods. Allocate compiles to a function that returns a unique integer and deallocate will compile to a function that takes an integer representing the instance to be deallocated and returns nothing.
- When inheritance comes into play, it's about either sharing functions or copying them.

That's all I can come up with on the spot. I might be wrong about something and I might have left something out. (I know I left out delegates and interfaces for one)

Thanks for this writeup on this. I still don't understand how custom extensions are actually possible, as it should only be possible from the compiler side, but meh, it doesn't really matter if it works. ^^

 

[Nestharus]

jasshelper compiler runs rather than WE blizzard compiler. It translates the stuff into plain JASS so that the map can load into wc3 =).

 

[Adiktuz]

Seems cool...

Seeing Maggy's example, I could imagine lots of possible things with this... Maybe I'll have a use for this when I decide to go back to making maps... Probably for creating additional things to damage systems and such...

 

[Zwiebelchen]

Seems cool...

Seeing Maggy's example, I could imagine lots of possible things with this... Maybe I'll have a use for this when I decide to go back to making maps... Probably for creating additional things to damage systems and such...

It would also be pretty need for things like buff systems.

You can basicly have a "basic" buff struct and then extend different types of buffs, adding parameters which are needed and leaving those which are not needed. Could improve the performance and code length of buff systems by a lot, to leave out the redundant stuff.

 

[mckill2009]

I really dont see the point in this than just an automated arrays of different indexes...

 

[Nestharus]

This has nothing to do with arrays :|

It's used to define object types and track inheritance.

Object Damage
Object Magical Damage extends Damage
Object Elemental Damage extends Magical Damage
Object Fire Damage extends Elemental Damage


Now in damage, if you want something to run whenever the unit gets hit by magical damage, that magical damage will catch all subtypes. If you want it to just be fire damage, it'll just be fire damage and possible subtypes of fire damage.

if (damageType.extends(DamageType.MAGIC)) then

Extends and isParent return true when damageType == targetType as well

 

[Magtheridon96]

^THAT is a wonderful illustration of the use of this (Better than mine)

 

[Bannar]

I guess props to mckill2009. Few here wanted an answer about usefulness of this, but they gave up. Finally ssjXXX comes and Nes gives him what he wanted - or at least I think he did ^^

Almia lost in battle :X

 

[mckill2009]

This has nothing to do with arrays :|

it works like an array, remember also that you can store different object types to an array...

set hero[0] = 'Hpal'
set hero[1] = 'Hamg'
set hero[2] = 'Hkmg'
set d[0] = DAMAGE_TYPE_FIRE
set d[1] = DAMAGE_TYPE_COLD

 

[Magtheridon96]

Good luck doing extensions intuitively and readably with that.

 

[Almia]

Almia lost in battle

What battle?

 

[Adiktuz]

And good luck doing custom types and inheritance tracking using that...

 

[Bannar]

mckill2009 - your array would have to have multiple indexes refering to members it's connected to, what foreshadows a mess.