[% setvar title Ensuring Perl's object-oriented future %]
To see what is currently happening visit http://www.perl6.org/
Ensuring Perl's object-oriented future
Maintainer: John Siracusa <firstname.lastname@example.org> Date: 16 Aug 2000 Last Modified: 28 Aug 2000 Mailing List: email@example.com Number: 126 Version: 2 Status: Frozen
Object-oriented features were added to Perl with version 5, and in many ways still appear somewhat "tacked on", with perhaps undue respect for the Old Ways of Perl 4. We have a chance to change things for the better with Perl 6.
Perl 6 should allow object-oriented programming with the same ease and efficiency that it allows procedural programming.
There are many RFC's already on objects and classes in Perl. I'd like to tie all the disparate implementation-specific RFC's together with a unifying direction: ensuring that people who like to program with object-oriented Perl get the native language features they need to do so cleanly and efficiently.
There are a lot of stumbling blocks to efficient object-oriented programming in Perl 5. It's great that the implementation allows so much flexibility, and some very clever things can be done with all that rope (see Damian Conway's wonderful book), but to quote Larry Wall:
"Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something."
Guess how many ways there are to make classes and objects and methods in Perl. The bottom line is that we're really using hashes and arrays and scalars and the concept of "blessing" to dandy up Perl 4 into an object-oriented language.
This wouldn't bother me so much if it wasn't also incredibly inefficient relative to procedural Perl. Of course object-oriented design will always have more overhead, but it shouldn't have that much more.
To put it another way, no one should ever be tempted to do this:
for efficiency reasons inside a tight loop or what have you. (And no, the solution is not to "use C when you need efficiency." I shouldn't need to use portable assembler to access an object attribute efficiently.) Whatever the syntax turns out to be, simple things like object attribute accessors should not only be faster than doing this in Perl 5:
they should even be faster than the naughty, encapsulation-destroying, implementation-revealing hash-lookup above. As for performance relative to procedural Perl code, I'm thinking something along the lines of Objective C's efficiency vs. plain C. Objective C is nearly as dynamic as Perl and doesn't give up too much to plain C in terms of execution speed. (And as a superset of a procedural language, it's a good analogy for Perl's o-o implementation.)
I don't think pseudohashes and such go far enough. I don't want "faster hash-based objects" or just "faster method dispatch", I want real, honest to goodness classes with attributes and methods and such that are distinct, both in syntax and implementation, from other Perl data structures like hashes and arrays.
Yes, this may force Perl 6 to make decisions about exactly which object-oriented features will be "natively" supported in Perl. But this is not all bad. After all, someone somewhere decided how the procedural stuff should work; there aren't 50 ways to return a value from a function, for example. Decisions have to be made and syntax has to be created. There will still be plenty of Ways to Do It, in my opinion.
The old procedural model should remain, of course. I'm not advocating a Java-like transformation into object-oriented bondage. And I'm not saying that every one of Perl's internal functions and operators should be replaced with object-oriented variants. All I'm asking for is a better world for object-oriented Perl programmers.
I think it's important to focus on this so it doesn't get lost in all the discussion of new letters to tack onto "m/.../sogie" and new syntax for range operators and such ;) And I think it's something that everyone can agree on, since there's a lot of benefit to be had, and no down-side that I can see.
Let's make Perl 6 an awesome language for object-oriented development.
That's up to the other relevant RFC's.
According to the author, this is a "mission-statement" type of RFC, rather than a specific feature request or proposal. It generally seemed to meet with approval and has therefore been frozen. This RFC has since spawned many more specific RFCs that are currently hashing out the more concrete details of Perl 6 OO.
Damian Conway's "Object Oriented Perl"
RFC 95: Object Classes
RFC 73: All Perl core functions should return objects
RFC 80: Exception objects and classes for builtins
All the other present and future RFC's dealing with object-oriented Perl 6 features.