- Joined
- Jul 10, 2007
- Messages
- 6,306
Please graveyard this. It was updated and moved into Mfn (just a macro now)
Last edited:
-
Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
-
Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.
[vJASS][Library]HTN- Handle Typecasting
- Joined
- Feb 22, 2006
- Messages
- 752
How does this have anything to do with typecasting? It's just a bunch of wrapper structs for handles. And what's more, the wrappers don't even provide extra functionality, so there's really no point in using them.
And you don't need to null struct fields.
And you don't need to null struct fields.
- Joined
- Jul 10, 2007
- Messages
- 6,306
Well, here's an example from something I am doing-
1. Users define their own object by extending a prototype object. Users may customize any portion of their object while the prototype still handles all ambiguous operations. This is done by creating stub methods that handle specific operations for the handle. The only problem is how does the prototype manipulate the handle without knowing what it is, and how do you keep this handle within the interface?
-Private variable of the handle cannot be used as it cannot be accessed via the interface. Defining a variable in the interface requires that it have a specific type, thus the private variable could not be declared within the interface meaning that it cannot be accessed by it. Because of the ambiguity of the system (you never know what types of objects you are handling), you must access objects initially from the interface within the prototype.
-Using a hashtable would be messy and complicated as you would be required to pass either the entire hashtable each time or an integer referencing an index in the hashtable, which requires yet more variables and more complexity and makes everyone's life hard.
-Using a set of structs allows the struct instance to be used without knowing what it is. The integer can also be passed from method to method and accessed quite easily.
-In my specific thing, only certain handles can be used. These are handles with
an X and Y coordinate
an owning player
a type id
However, this can be expanded into a broad range of categories as handles can be given an artificial owner, artificial x and y coordinates, and even an artificial type id. This is due to the fact that the user of the system has control over getting the properties of the handle, meaning they can return whatever they like. The x and y coordinates are used for where the effects of the handle are to take place, the type id is used to create the handle's type (not needed), and the owning player is to create objects attached to the handle for a specific player (once again can be artificially done)
So how could this be useful? In cases where the thing that is being designed is extremely ambiguous
What does it have to do with typecasting? It allows users of those ambiguous designs to typecast data (it takes Unit u, but you cast it to an Item object) so that they may more easily use the construct while maintaining speed.
A very simple library of structs named after handles
^_^
1. Users define their own object by extending a prototype object. Users may customize any portion of their object while the prototype still handles all ambiguous operations. This is done by creating stub methods that handle specific operations for the handle. The only problem is how does the prototype manipulate the handle without knowing what it is, and how do you keep this handle within the interface?
-Private variable of the handle cannot be used as it cannot be accessed via the interface. Defining a variable in the interface requires that it have a specific type, thus the private variable could not be declared within the interface meaning that it cannot be accessed by it. Because of the ambiguity of the system (you never know what types of objects you are handling), you must access objects initially from the interface within the prototype.
-Using a hashtable would be messy and complicated as you would be required to pass either the entire hashtable each time or an integer referencing an index in the hashtable, which requires yet more variables and more complexity and makes everyone's life hard.
-Using a set of structs allows the struct instance to be used without knowing what it is. The integer can also be passed from method to method and accessed quite easily.
-In my specific thing, only certain handles can be used. These are handles with
an X and Y coordinate
an owning player
a type id
However, this can be expanded into a broad range of categories as handles can be given an artificial owner, artificial x and y coordinates, and even an artificial type id. This is due to the fact that the user of the system has control over getting the properties of the handle, meaning they can return whatever they like. The x and y coordinates are used for where the effects of the handle are to take place, the type id is used to create the handle's type (not needed), and the owning player is to create objects attached to the handle for a specific player (once again can be artificially done)
So how could this be useful? In cases where the thing that is being designed is extremely ambiguous
What does it have to do with typecasting? It allows users of those ambiguous designs to typecast data (it takes Unit u, but you cast it to an Item object) so that they may more easily use the construct while maintaining speed.
A very simple library of structs named after handles
^_^
- Joined
- Feb 22, 2006
- Messages
- 752
Why would you ever want to do that? And exploiting jasshelper's lack of struct typesafety isn't a good idea. I do believe Vex has said he plans to introduce typesafety eventually to jasshelper.
- Joined
- Jul 10, 2007
- Messages
- 6,306
So you can let the user have full power of exactly what they want to define. Maybe I design a system that has more purposes than I can think of and someone goes, oh cool, I could use it for this, but it doesn't support it so I gotta cnp and change all of this code /cry
Well, this makes it easy... also, I'd like to support 2 handle types fully in a system I am designing right now. For other handle types, people would have to do some artificial things for the properties I got : P.
I found a great need for this library (unless I wanted to create an internal library for supporting the 2 handle types, and I don't believe in internal memory that can be used by other things ^_^, only stuff specific to the system or w/e should be internal).
Personally, whenever I design something that's meant to be used by designs of other people, I believe in letting them do w/e they like with it without having to modify any of the actual code. This is one thing that does allow that to be done easily = D.
Well, this makes it easy... also, I'd like to support 2 handle types fully in a system I am designing right now. For other handle types, people would have to do some artificial things for the properties I got : P.
I found a great need for this library (unless I wanted to create an internal library for supporting the 2 handle types, and I don't believe in internal memory that can be used by other things ^_^, only stuff specific to the system or w/e should be internal).
Personally, whenever I design something that's meant to be used by designs of other people, I believe in letting them do w/e they like with it without having to modify any of the actual code. This is one thing that does allow that to be done easily = D.
