We're foretold that Perl5 code will be swollowed by the Perl6 implementation because it will have a different parser front-end, even though Perl 6 syntax will be somewhat different.

OK, but what about objects?

Perl 6 will have more "official" support for doing objects in a particular way, and have built-in syntax for doing this succintly. In Perl 5 we are pretty much on our own and can do things any way we want. We aren't really even limited to the built-in method dispatch system, as the multi-method dispatcher by Conway shows.

The problem with this flexibility is the difficulty in extension. Different libraries have different ways of inheriting them. You have to know too much about how they really did do it.

By having a common mechanism, this will be addressed. But what about old classes? Obviously, we must still have the old virtual dispatch mechanism supported, so that we can trivially migrate to Perl 6 by doing some minimal syntax rule changes without (yet) doing a whole paradigm shift. More seriously, how do we use and inherit from objects written in Perl 5 code?

If all the old mechanisms continue to work (modulo some syntax), then we are no worse off and the user needs to understand the implementation to extend it, just like we have now.

But it would be even better if the new built-in syntax features of Perl 6 were available, even though we're using Perl 5 objects.

In the same way that Win32::OLE can magically create objects based on the COM type library, a Perl 6 program could have a facade object that actually generates the plumbing to call the Perl 5 object, in whatever manner the Perl 5 object was written.

Calling is easy; almost always it uses the blessed reference virtual function dispatch, and this kind of wrapper can be assumed. Inheriting is harder. Is the Perl 5 object using a blessed hash or array, and what naming conventions does it use to separate private variables of different parts of the hierarchy? This will need to be tuned on a case-by-case basis, to match the particularities of each legacy class.

That's an interesting meditation. But closer to home, what does that mean to us today? In writing a set of related Perl 5 classes today, how do I approach the project to best be ready for Perl 6?

—John

  • Comment on Perl 6 Objects and Backward Compatibility

Replies are listed 'Best First'.
Re: Perl 6 Objects and Backward Compatibility
by Elian (Parson) on Oct 11, 2002 at 18:36 UTC
    Perl 6 classes should be able to inherit from perl 5 classes--this isn't any different a problem than inheriting from Java classes or .NET classes. Going the other way may be more problematic, but we'll see.

    When you inherit from a perl 5 class, you'll treat the inherited portion of the object as if it were opaque, which is probably the best thing to do in an inheritance situation in general, and parrot will handle the automatic delegation in such composite objects.