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

>     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 :)


Reply via email to