Stunt, property definition/removal on anobj parents

[Leviathan-7]

for one, i'm sorry to make a 3rd consecutive post about this stuff.

is there any reason why anobjs are invalidated if you define/remove a property to/from the parent of one? is it at all possible for this not to happen?

[Jason SW]

Apparently this is documented behavior, though the documentation was
hard to find. I hope this can be improved as well, as anonymous objects
would be much more useful without this ... Feature. As it is now, if you
use anonymous objects for an account based login system, or as exits, if
properties get added or removed on the parents, those objects are
permanently lost. Quite annoying.

> --
> You received this message because you are subscribed to the Google
> Groups "MOO Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to MOO-talk+u...@googlegroups.com
> <mailto:MOO-talk+u...@googlegroups.com>.
> To post to this group, send email to MOO-...@googlegroups.com
> <mailto:MOO-...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/MOO-talk.
> For more options, visit https://groups.google.com/d/optout.

[Leviathan-7]

yeah, a patch to fix this would be an enormous improvement. waifs didn't have this issue though they liked to crash.

[Todd Sundsted]

The issue arises from the way properties are laid out in memory for an object (anonymous or permanent). When you add/remove a property to a parent (in Stunt or LambdaMoo) the server visits *every* child and modifies the layout of the properties to account for the change. In order for that to happen, the parent has to maintain a reference to every one of its child objects. I wanted to be able to create 1000's or 10,000s of anonymous objects without a second thought -- parent references to each of these anonymous children would consume an unacceptable amount of memory, not to mention add a tremendous amount of overhead when properties change. The solution is to change the way properties are managed, but that's not a trivial change. Waifs try to fix things up lazily, as waifs are accessed after parents are modified, but it fails to handle tricky edge cases, so I decided to take the simple, but well-defined (if poorly documented) route and just invalidate the children (until a better solution comes up).

Todd