Larry Wall wrote: > On Fri, Jan 20, 2006 at 09:35:13PM +0800, Audrey Tang wrote: > My original intent was #2, hence the wording in A12. But to speak to > some of Stevan's concernes, there's something going on here which is > not quite "Object does Hash". It's more like "Object can do Hash", > in the linguistic sense that a "Noun can do Verb", but nonetheless > remains a noun. A fallback role is not the same as a normal role. > Maybe there's some way to mixin in a fallback Hash role without > clobbering a real Hash role that is already there, so that if your > Hash container is an object you don't see methods for its keys. > > Something like this might also let us distinguish p5ish scalars that > are simultaneously Num and Str from scalars that, say, intrinsically > do Num but can emulate Str in a pinch without caching the result. > I don't think we have a good way of expressing that distinction right > now.
I agree it is a hairy subject, but the more I think about this (and the more i read about and play with CLOS) I think we might be able to accomplish something very close to this by creating more special purpose attribute meta-objects. By moving much of the actual attribute accessing work to the attribute meta-object, we can very easily have arbitrary object "types" since all their access is mediated through the attribute meta-object. In CLOS this would be accomplished by subclassing the standard-class, and telling it to use the different attribute meta-object by default. The of course you slap a juicy LISP macro around it, and you are ready to go. Mmmmmm LISP macros :) Basically my point is that the meta-classes and meta-objects govern the behavior of the classes and object. So if we want to change the behavior of our classes and objects, we just subclass the meta-classes and meta-objects and specialize the behavior as we desire. > This seems to imply that a given role like Hash could have two default > implementations--one for an actual Hash container, and one that emulates > a Hash by deferring to the Object. It's sort of like a role that can > delegate back to its own object. This should all be possible with attribute meta-objects. Basically when we encounter this type of need (in p5->p6 translated classes, or otherwise), the compiler (or possibly the translator) needs to discover this need, and change the metaclass appropriately. The self delegation then Just Works. Of course this is all just hand-waving right now since the current metamodel does not support such deep magic. But hey, I have been thinking it might be time for a v3 soon anyway :) > Such issues arise whenever you start making statements of the form > "I want to use an A as if it were a B." The problem is much bigger > than just how do I translate Perl 5 to Perl 6. It's questions like: > > What makes a particular metaphor work? > Will the cultural context support use of an A as if it were a B? > How do we translate the user's thoughts to the computer's thoughts? > How do we translate one user's thoughts to another user's thoughts? > How do we know when such a translation is "good enough"? > How do we know when our mental model of an object is adequate? > How do we know when the computer's mental model of an object is adequate? > What does adequate mean in context? I am actually working with Rob Kinyon on a meta object protocol for Perl 5 for our $work. It does not try to make Perl 5 anything it is not, instead it only attempts to define the workings of the Perl 5 object system and provide clean hooks into it. It is in the very early stages, and needs lots of testing, but it might help to bridge the two models. > Will the culture support partially instantiated objects? :-) Hmm, do you mean lazy objects? As in, only instantiated as much as is absolutly necessary at a particular moment? I recently read a paper on an extended version of CLOS (yay CLOS) which demonstrated how lazy classes could be built, including ones with strict initialization orders ($a must be initialized before $b, but $b depends on $c, etc). But maybe this is not what you mean. Or is this the "class but undef" idea again? Audrey and I have "solved" this by creating a 'p6undef' repr type which allows the class to be instantiated and methods called on it, but if you try to access anything other than basic meta information, it will fail (because it's just undef). Actually, I think this partial object thing needs it own thread really. But I will let you decide when you are ready for that one :) Stevan
