Austin Hastings <[EMAIL PROTECTED]> writes:
> Of course, how hard can it be to implement the .parent property?
.parent and also .children, plus .moveto and .remove (which doesn't
actually destroy the object but sets its parent to undef, basically,
cleaning up the .children property of its parent), and a couple of
extra routines for testing ancestor relationships and stuff, but...
> You'll want it on just about everything, though,
Right, it would be less useful if not all objects had it. Although it
would be easy enough to implement a class of container object that
implemented the forest and each contained a .node which could hold
some other kind of object. That adds a layer of indirection, but it
would allow for organizing arbitrary objects using the forest.
In Inform any object with no parent is on the forest floor, but it
would be easier to implement I think by making the forest floor an
object, and having all of the forest-container objects be located
there by default and having .remove move them there. Then the forest
floor's .children would take care of the ability to iterate over all
the toplevel objects.
This approach has the advantage of not needing any changes in core.
Maybe I just won't sweat it. A lot of the things Inform programmers
do with the object forest can be done in Perl in other ways, combining
hashes and references and arrays and stuff (stuff Inform doesn't
really have per se; well it has (statically-sized) arrays, and it sort
of fakes references... but it's not the same). Properties are the
thing that was harder to get around a lack of, and we're getting those :-)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
