PDA

View Full Version : using structure to represent a tree.


boomji
01-13-2009, 10:01 AM
would appreciate how one would go about doing this.

1.I have a tree which is represented with base(cylinder) and top(cone)
2.i wanted to pass a modifier to any part(top or base) so i'd like to be able to refer to each part with it's logical name.
3.Representing this in a structure "seams" ideal.

Problem is when i declare a variable of the struct type i assume it should be fool proof and not be able to be overwritten with any other data.


struct tree (treeBase = ( cylinder() ), treeTop = ( cone() ))--declare

tree_01=tree() --create tree object
tree_01.treeBase.name="testTree" --some tests to see if all is good
addmodifier tree_01.treeTop (bend()) --all ok so far.
tree_01.treeTop="foolProof" --why am i being allowed to change the contents of this

How can i prevent my self from overwriting the contents(members) of my tree_01 object.

Thanks a bunch.


b

shibumenon
01-13-2009, 11:16 AM
Protected, private and public members are features available only when writing a class, not in a struct. And unfortunately, maxscript is not oo, so no classes in here.
Same is the case if you program in C. These features are available in a C++ like OO language. The member variables cannot be privatized/protected. But you can kindof protect your functions:
struct tree
(
theTop= undefined,
theBase = undefined,
fn treeBase =
(
theBase = cylinder()
),
fn treeTop =
(
theTop = cone()
),
fn initTree =
(
treeBase()
treeTop()
)
)--declare

shibumenon
01-13-2009, 11:33 AM
while on the topic of struct, it'd be great if there could be some enhancement to structs in one of the future releases ... public/private in a maxscript struct ? That would be awesome :)

boomji
01-13-2009, 12:00 PM
Thanks shibu :)

I'm surely overlooking something in your design as far as intended use.
Because i can still create a variable called
tree_01.theTop="foo" and ruin everything :curious:

I'll embarrass my self once again:
Would python help here ???


b

drdubosc
01-13-2009, 12:12 PM
You can't protect a MXS struct variable from direct modification, as achoo said. There are no access modifiers in the language. You have to do it by convention: eg. "I'm private" naming ( _base, _top ) for member variables, and the provision of accessors ( getBase(), setBase()) etc. Most clients will understand the initial underscore means "hands off".

shibumenon
01-13-2009, 12:47 PM
hmmm ... interesting.
one twisted workaround would be this :
write your tree struct and come up with some really abstract unthinkable name for the top and base members.
struct tree
(
gobledeeeGookTheTop= undefined,
gobledeeeGookTheBase = undefined,
fn treeBase =
(
gobledeeeGookTheBase = cylinder()
),
fn treeTop =
(
gobledeeeGookTheTop = cone()
),
fn initTree =
(
treeBase()
treeTop()
),
fn getTop =
(
return gobledeeeGookTheTop;
),
fn getBase =
(
return gobledeeeGookTheBase
),
makeTree = initTree()
)--declare

Now make sure that your maxscript file has only the above struct , encrypt your script and make the encrypted version available to the next level of developer.
Also, create a second struct, kind of a wrapper struct, thro which the next level of developer can access your tree struct

struct treeMaker
(
tree_01=tree(), --create tree object
fn getBase = tree_01.getTop(),
fn getTop = tree_01.getBase()
)

myTree = treeMaker()
varr1 =myTree.getBase()

boomji
01-13-2009, 02:13 PM
whoaaa...:wip:
This rabbit hole doesn't seam to end ;)
Thanks again shibu.


b

shibumenon
01-13-2009, 02:41 PM
yes, it doesn't end !
This is not really as foolproof as we'd like.
If you really want to crack it, you can use
sss = getPropNames tree
to figure out whats there in the hidden struct !!

or better still, just do some buggy code with the tree struct, and
maxscript promptly hands out the entire structure of your hidden struct to you in red on to the listener as an error :D

drdubosc
01-13-2009, 03:20 PM
Let's face it, MXS is for scripting, not heavy-duty programming? Access modifiers, inheritance, and so forth, only really come into their own in larger, or more collaborative projects, especially when writing compiled libraries, IMO, although I often miss the way of thinking that would come with full-featured OO, and it would make community-written libraries easier to produce. It would be lovely if the SDK was easier to write to, but maybe that's just me being hopeless :).

CGTalk Moderation
01-13-2009, 03:20 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.