Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Speaking of objects... are we going to have a built-in object
>> forest, like Inform has, where irrespective of class any given
>> object can have up to one parent at any given time,
>
> Multiple parent classes, yes.
Not remotely the same thing.
> Parent objects, no.
Oh, well.
>> and be able to declare objects as starting out their lives with a
>> given parent object, move them at runtime from one parent to
>> another (taking any of their own children that they might have
>> along with them), fetch a list of the children or siblings of an
>> object, and so forth?
>
> Erm.... I don't think so. I get the feeling that Inform had a
> different view of OO than we do.
I was asking mainly because Perl6 was moving in that general
direction. Having compile-time traits but also being able to tag
properties on at runtime is very Inform-like. Inform's object model
also fits pretty well with Perl's notions of context, things like
being able to treat someobject.someproperty as a value and not care
whether it's actually a value (the more common case) or whether it's
really a routine that returns a value each time (the more flexible
case), for example; in Perl6 this will be accomplished more likely by
returning an object that has the desired numerify routine so that the
caller can just assume it's a number and not get surprised, but that
amounts to ultimately the same flexibility.
So I was just wondering about the _other_ useful feature of Inform's
object model, the object forest. However, this is the sort of thing
that could be added to a later version without breaking any existing
code.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
