AddProtectedField() - grr
by Orion Elenzil · in Torque Game Engine · 12/07/2007 (11:20 am) · 3 replies
Seems like the Offset parameter of addProtectedField() is a bit meaningless, neh ?
should the accessors be responsible for what Offset does w/ an accessor-less field ?
ie, suppose my getter() is just return("hi there!");,
then the offset is totally meaningless.
i understand it's there to shortcut some common cases,
but i think it confuses the architecture, and forces you to provide inconsistent calls.
for example,
suppose my protectedField is something very procedural, such as allSubObjectsColoredBlue.
there is *no* member field which corresponds to that, yet addProtectedField() requires me to provide an offset to one.
should the accessors be responsible for what Offset does w/ an accessor-less field ?
ie, suppose my getter() is just return("hi there!");,
then the offset is totally meaningless.
i understand it's there to shortcut some common cases,
but i think it confuses the architecture, and forces you to provide inconsistent calls.
for example,
suppose my protectedField is something very procedural, such as allSubObjectsColoredBlue.
there is *no* member field which corresponds to that, yet addProtectedField() requires me to provide an offset to one.
About the author
#2
i'd assumed the intent was to provide fields which operate through implicit setter/getters.
the exact issue we're running into is we have a bit in a bitfield (netObject::mNetFlags) which we would very much like to expose as a "bool" member field for use in the mission file.
you see the quandry.
12/07/2007 (11:37 am)
I guess i am confusing the intent.i'd assumed the intent was to provide fields which operate through implicit setter/getters.
the exact issue we're running into is we have a bit in a bitfield (netObject::mNetFlags) which we would very much like to expose as a "bool" member field for use in the mission file.
you see the quandry.
#3
For exposing just a certain bit within a bitfield however, you might want to play around with validators via ConsoleObject::addFieldV(..).
There aren't any examples for use within stock TGE as far as I can tell, but the AFX kit uses them if you happen to have that pack.
The reason for the offset macro by the way is because you are providing runtime access to specific memory locations, and to maintain cross platform, we need to be able to find the actual memory location the data resides in, which can be different on different platforms. You may be able to expand ::addFieldV() and offset to allow access to specific bits within a class member variable, but that's not implemented in stock.
12/07/2007 (12:04 pm)
It's not quite implicit setter/getter (not like C# for example), but it does have some of the properties.For exposing just a certain bit within a bitfield however, you might want to play around with validators via ConsoleObject::addFieldV(..).
There aren't any examples for use within stock TGE as far as I can tell, but the AFX kit uses them if you happen to have that pack.
The reason for the offset macro by the way is because you are providing runtime access to specific memory locations, and to maintain cross platform, we need to be able to find the actual memory location the data resides in, which can be different on different platforms. You may be able to expand ::addFieldV() and offset to allow access to specific bits within a class member variable, but that's not implemented in stock.
Torque 3D Owner Stephen Zepp
It's not designed at all for tying together script "fields" with non-class member variables such as lists/vectors/sets, etc.
In the sample case you gave, I'd just make that a ConsoleMethod, since there isn't a single class member variable you want to query, but a run time dynamic list (it seems) of objects.