>>set shareProps(textFont,backgroundColor,script) of fld X of stack S to true >>duplicate fld X of stack S in card 2 of this stack > >Andu, > > I hate this syntax. Get a life ;-) > Why don't we just add a new property "the >sharedProperties" which contains a list of the properties that are shared: > > set the sharedProperties to "loc, rect, highlight, text" > set the sharedProperties to empty -- all are card-local > set the sharedProperties to the properties of me -- all are shared > >This is much more xTalk-y. BTW, do we already have "the properties" >property in MC? HC has this for its xWindows, and it's the most sensible >choice. > >Cheers, >- -- M. Uli Kusterer > >But there are still a lot of issues here: >1) What happens when you get or set a shared property? Does >"effective" work here too? Does it override the "shared" property and >remove it from the list in the sharedProperties? I think that would defeat the purpose. >2) How is the hierarchy defined? Is there a "sharedParent" property >or something? If so, is it another real object and can it have shared >properties of its own? I don't know what you mean by a "sharedParent" property but if you refer to "children" having shared properties of their own my answer is yes. Sort of like a tree. >3) How does this solve the composite-object problem? Are the >"children" of a group one of the things that can be shared? I don't think so. That would make keeping track of a more complex project a nightmare. That would be the same as when you clone a stack to also get all the substacks of it in the clone. Imagine the long name of such an offspring of an offspring. I think this concept of shared properties could be very useful as long as it's kept simple in purpose. It can evolve as people get used to it and new needs arise. > Regards, > Scott Regards, Andu
