White Camel Award Nominations

Idmat writes "Nominate the Perl community's unsung heroes for the first White Camel awards. Three awards--for outstanding contributions to Perl Advocacy, Perl User Groups, and the Perl Community--will be awarded at O'Reilly's Perl Conference 3.0 on August 24, 1999. Nominate the folks who have made these important non-technical contributions to Perl at perl.com All nominations must be in by August 2. The White Camel awards are sponsored by Perl Mongers, O'Reilly & Associates, and sourceXchange. See the press release for more info " Anyone want to share their ideas?

Comments

Re:COBOL of the 90's

[Tom Christiansen]

What? Spend more time writing code then trying to count the curly braces?

You would prefer perhaps mental telepathy?

If you're counting braces in C, Java, troff, awk, C++, Perl, Javascript or any of the rest, you're doing something fundamentally wrong. That's the computer's job. Perhaps you should try a more sophisticated editor than ed. :-) Really, balanced braces and alignment of code are the job of your editor to help you with.

Re:Hear, Hear!

[Tom Christiansen]

Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's

Very much so. Larry Wall had been using C++ for a few years before he added object support to Perl. He did so at least partially so he could interface with C++ using a simpler language.

When it came time for the object design, he rejected much of the C++ model. That's probably just as well, since C++ has so many oddities not found in any other language with object support. Python's model seemed sufficiently clean and appealing that, as with so many other tools and languages where Larry "cherry-picked" the coolest property from eclectic sources, he took most of the object stuff from Python.

For example, the object's self reference (the "this" pointer) coming in as the initial argument in a method call rather than as a formally defined variable comes right from Python.

Of course, we weren't really content to stop there. One difference from Python is that the class itself can serve as something of a meta-object. This has some rather nifty ramifications to this. If you're filling out a check-list of features, you'll find that Perl OO programming supports classes and objects, single and multiple inheritance, instance methods and class methods, access to overridden methods (a virtual SUPER class), constructors and destructors, operator overloading, proxy methods via autoloading, delegation, a rooted hierarchy for all objects (class UNIVERSAL), and two different levels of garbage collection.

Before you diss it too much, you should know what Perl OO is actually about. If you're looking for more information or examples on Perl OO, here are some suggestions:

• The perltootc manpage, for managing class (and sometimes instance data) in Perl.
• The perltoot manpage, a tutorial for OO in Perl
• The perlobj manpage, a rather dry but essential page.
• The overload manpage, to see how operator overloading works with Perl objects.

• The Perl Cookbook (yes, my name is on the cover) has a chapter on objects. You can download the source through the Examples link there (either normal gzip or else Wintel zip format).
• A new book (that yes, I tech-edited, but no, which I don't get royalties on) is coming out by Damian Conway, called simply enough Object Oriented Perl. Damian is our Melville. :-) We've accepted three of this prolific fellow's papers in the refereed track at the next Perl Conference. One of them is even a technical paper that's written completely in a certain kind of poetry.

I don't mean to pretend that Perl's OO doesn't have its host of issues. The biggest one is that unless you're careful in your design, one class needs to get unnaturally chummy with its parent class to avoid accidentally overriding or interfering with not just functional members (methods) but also data members (attributes).

But as Larry has said: `Concentrate on Perl's strengths, not its weaknesses.'