Lambda the Ultimate

I haven't read it carefully yet so I won't go into technical details, but here's one amusing bit.

Of course, the really funny thing is that if you go across a language barrier like that, Perl might just decide to emulate the inheritance with delegation anyway. But that should be transparent to you. And if two languages manage to unify their object models within the Parrot engine, you don't want to suddenly have to rewrite your roles and classes.

And the really, really funny thing is that Parrot implements roles internally with a funny form of multiple inheritance anyway...

Ain't abstraction wonderful.

It seems that the most interesting sections are Dispatch Mechanisms and Class Composition with Roles

is prototype-based oo supported by the way perl does things anyway? of the various words i searched for, prototype got surprisingly few hits.

As in Perl 5, a class is still "just a funny package", structurally speaking. Syntactically, however, a class is now distinct from a package or a module. And the body of a class definition now runs in the context of a metaclass, which is just a way of saying that it has a metaclass instance as its (undeclared) invocant. (An "invocant" is what we call the object or class on behalf of which a method is being called.) Hence class definitions, though apparently declarative, are also executing code to build the class definition, and the various declarations within the class are also running bits of code. By convention classes will use a standard metaclass, but that's just convention. (A very strong convention, we hope.)

Classes may also be used as objects in their own right, as instances of a metaclass, the class MetaClass by default. When you declare class Dog, you're actually calling a metaclass class method that constructs a metaclass instance (i.e., the Dog class) and then calls the associated closure (i.e., the body of the class) as a method on the instance. (With a little grammatical magic thrown in so that Dog isn't considered a bareword.)

The class Dog is an instance of the class MetaClass, but it's also an instance of the type Class when you're thinking of it as a dispatcher. That is, a class object is really allomorphic. If you treat one as an instance of Class, it behaves as if it were the user's view of the class, and the user thinks the class is there only to dispatch to the user's own class and instance methods. If, however, you treat the object as an instance of MetaClass, you get access to all its metaclass methods rather than the user-defined methods. Another way to look at it is that the metaclass object is a separate object that manages the class object. In any event, you can get from the ordinary class object to its corresponding metaclass object via the .meta method, which every object supports.

Sorry to quote so much of it. But, when this came out, one of the first things I wondered is how much Perl 6's OO would be based on prototypes. I don't have a good handle on how having metaclasses is different than having an object system based on prototypes. If someone would like to elaborate on this I'd appreciate it.

Why are these similar?

To be honest, I don't really grok how metaclasses work. But, if your classes are objects, how is that different than having a class be considered a prototype that its objects are copied from? Or, are having metaclasses and having a prototype-based object system orthogonal to each other?

I apologize if I'm just wasting your time with my ignorance. If I'm just way off base, please say so and I'll go off and find things to read until I get it.

[1] I watched a video demonstration of the Self system a while ago and they had objects dynamically change behavior based on changes made to their parent classes. Though, I'm not sure Perl 6's scheme will be this dynamic.

Some LtU linls: #1, #2 (Python tutorials, Mertz); ST's Behavior

Please keep asking. These are confusing ideas...

on the other hand, since you have metaclasses (and presumably introspection) you can probably write a metaclass that makes a class by copying from another.

however, i don't know if that's how prototype based systems work. for example, presumably you wouldn't copy methods, but only pointers to them. i don't know what should happen if you modify a method in one instance...

if i said that every time i posted we'd never get anywhere ;o)

however, i don't know if that's how prototype based systems work. for example, presumably you wouldn't copy methods, but only pointers to them.

I think this is a good time to link to that Self video I mentioned. A Self object has slots that contain methods or data. If a method call is attempted on an object, it dynamically dispatches to each of its parents (which dispatches to *its* parents if not found, and so on) looking for the method with the right name. If you create a method on an instance that has the same name as an inherited method of its parent, that method is simply found first in the search.

If the method is defined in an instance that you make copies from, the method itself is copied. If you change the method in one object it doesn't affect the other.

That Self video is very cool, btw. If you haven't seen it yet, I'd really recommend checking it out.

I also wonder if the Perl culture of TIMTOWTDI (or whatever that acronym is), allows the language designers greater flexibility?

As for TMTOWTDI, it's primarily intended to make things easier for the user of the language. It generally makes things harder for the language designer, in my experience, but is nevertheless worth it.

You haven't been paying attention.

Speaking of which, after the dust settles, it'd be nice to see a "Design & Evolution of Perl" type book down the road (ala Bjarne). But I guess the Onion tracts kind of give us a real-time glimpse along those lines.

Sure.

Perl 6's OO is a sort of hybridization of what P5 had, what other high level languages in Perl's space like Ruby and Python have and something darn-near prototypes.

So, while it's similar I would say that there are significant deviations. For starters, there *is* such a thing as a declaration, it's just that the declaration is represented by an object of type Class, which also has properties (roles in P6 lingo) of type MetaClass. This object is *not* a prototype from which your objects will be constructed, but it is a blueprint, and it will be accessible from your object.

Why is that distinction interesting? Well, for starters, you cannot (as far as I've seen) derive from an object in P6. It would instead be a two-step process (gain access to an object's metaclass, then derive from that). There is a strong "has" relationship between an object and its class, not "is" as in prototyping languages that I have seen.

I'm not making any value judgements here, just laying out what I understand of A12.

As for the comments about not wanting to program in P6 because it sounds too scary (my words), I think everyone is missing a fundamental point here. A12 is a design document, not a reference manual. As such it is covering everything necessary to implement the language. There may be pieces of A12 that are hidden under the hood, or which standard "strict" or "warning" modes produce errors or warnings on for general use. They are there to provide the mechanisms by which the language will be implemented and extended.

For the most part, I don't see P6 programmers using $object.metaclass or altering the delegation model, but certainly both of those things will be required in order to implement the autoloader or dynaloader in P6 itself....

Hope this helps!

Thanks for the clarification. Never seen a design doc before...

(For the sarcasm-impaired: the last sentence was the joke, just like the remark about not wanting to program P6...)

1. Easier is in the eye of the programmer ;-)

2. You should check out the Parrot sources and give it a whirl. Great docs, though somewhat disorganized.

3. You can use Parrot today (with some caveats), but Perl 6 will not be out for at LEAST another year... you do the math. :)

P6 will be, I think, a very nice language, but if you want to play with some nice features that P6 promises, yeah Parrot is the way to go right now (and the Perl6::* modules for Perl5).