Hi Eric Et al.
I've only been using PErl for a couple of years and am not totally sold on
OOP yet, either. I'd like to address Some of the points you raised, though,
from a different angle. I've been thinking of Perl OOP for some time and
thought bringing up some of this criticism in comp.lang.perl.misc. But
frankly speaking, I havent' dared because of the pretty strict culture
against newbie:ish posts in there. I just feel like I might not be ready to
defend my stance in the big arena. But now that this came up in a
low-ttraffic list, here we go:
Roode, Eric wrote:
<snip>
> As for OOP, Perl is very OO. It has built-in support for data
> hiding, encapsulation, method calls, the whole ball of wax. Plus it
> has powerful reflection, run-time definition, and exception-handling
> capabilities. It is every bit as capable an OO language as Java or
> C++ or C#; just different. <snip>
Just different is the key to me. When initially trying to learn the Perl OO
basics after Java and C++, I thought what a hack, I mean who wants to use
such a thing. But after having abandoned it and coded some more, getting
accustomed to the Perl culture and way of thinking I returned to it. I made
an observation that in larger scripts I would write functions that
manufactured, ate, mangled and processed references to hashes as their first
argument. THen I happened to revisit Perl OOP first in beginning Perl which
explains it well, then in the Camel book and finally in the official docs.
At some point things just clicked. Perl OOp is a lot about passing in
references to hashes as instance data, with syntactic sugar and inheritance.
Now while I am not wild about Perl OO still, I can appreciate and understand
the design to a certain extent, as a minimalist way to retrofit OO on top of
the current design while keeping Perl Perl. and trying to make up creative
uses for the more exentric and dynamic ffeatures fills me with delight. I
find that when comparing Perl to most other OOpy langs, I often start my
sentence with "But in Perl you can ..." I did that just today when a Unix
friend of mine rantedd about how bad PHP OOP can be at times.
Anyway the problem with perl OO as I see it, is not that the language would
not be up to it, but how alienated OO seems to be from the average Perl
module. I don't mind the purely procedural modules, in fact I like most of
them, but the average OO module seems to be just a bunch of functions for
working with one or two kinds of blessed hash. I mean, it really, quite
often, is not much more OOpy than a good C library. The fact that you can
ducktype, i.e. call similarly named methods regardless of inheritance, is
often very powerful but it also does mean that more often than not there's
no real official interface specification at all, even in modules that would
benefit from one. That in turn means that reuse of modules is not that high,
though I've seen quite many that piggyback on various Internet clients.
Another trend is shyness about abstraction. It's funny I should mention this
as I switched from Java to Perl to avoid abstraction when it felt especially
daunting in small scriptlets. Anyway, where libs for other langs would let
you inherit from a class or plug in an interface implementation, many Perl
modules are quite happy with a sub-routine reference. IT would be OK if that
was a wrapper for some OOPy concept but your average coder will false-lazily
try too a procedural solution first, when tempted. At least I tend to do
that, <blush>. Compare this to Java's system of listenre classes or C#, in
which even a basic window requires that you inherit from a well-defined
class. There's WX Perl, of course, but even in its intro in www.perl.com the
author said that he found it uncanily oopy and somewhat Unperlish, or
something to that effect, which is quite teling.
While I do think Java is often overkill in this regard, and often am happy
about Perl's straightforward take on things, many many modules could do with
more abstraction. Take the modules in the MIDI namespace, for instance. THey
offer you, nothing more abstract and grander, than a plain reference to an
array whose structure varies from one module to the next in the set.
Contrast that to the variety of classes, nicely named accessor methods and
such that you get in the java standard classes for MIDI. Sure that's
abstract as heck and could be documented better, but still. They aren't tied
to the underlying data format, either, though I'm sure that won't change for
a while. MIDi has been round for 20 years or so and I've tinkered with it
for the last 10 mostly recreationally through a sequencer.
Another problem is that there are no standard ways to iterate over things
apart from foreach and tied handles. I'm not sure if OOPy interfaces in the
core modules would solve this but there's an amazing variety of slightly
incompatible iterators and implementations of map, grep et al using them.
This is at least a tentative notion I have after having read most of
HIgher-Order Perl and taken a look at various modules for more specialized
data. In contrast, the iterator interfaces in C++ STL or Java are nowadays
well established, though I recall the time when that was not the case for
Java.
Lastly howabout error handling. That's something that surely needs
improvement. I've seen many procedural and OOPy modules whose author's don't
bother to use or at least explain errno values against which you could match
and take different actions to recover gracefully and as smartly as possible,
from the user point of view. EQuallly many are classes with string-based
exceptions that go undocumented. While I'm a big fan of the x or die "canot
x due to $^E" style, it doesn't always do in large programs or GUis. There
is the ability to make exception classes with specific info and sensible
names, but how many modules do use them and is there again anything like a
defacto standard base class for them? Looking at docs for modules, there
are two things that caught my eye. While not deadly at all, they certainly
discourage OOP and you feel like having to invent hacks to stay OOPy. This
is Perl 5.8.7.
Quote perldoc carp:
Bugs
The Carp routines don't handle exception objects currently.
End quote.
quote perldoc -f die:
Although this feature was to be run only right before your program was to
exit, this is not currently the case--the $SIG{__DIE__} hook is currently
called even inside eval()ed blocks/strings! If one wants the hook to do
nothing in such situations <snip>
End quote.
Oh and before I forget, I've been looking into Ruby. THe author said in a
book basically that he made Ruby easy, elegant and high-level for people to
create elegant programs that are smart and polite. That's in stark contrast
to the PErl culture and your average Unix app which might blurt out things
like cannot stat x". I wonder if this is, in fact the culture in Ruby coding
in general, or if the convenience is also greatly employed to quickly
compose quick-n-dirty programs for small jobs. Tiny apps I call scripts are,
in fact, an important feature and one of the reasons why I like Perl, but
the mentality can be a problem in large software, including habits you'l
have to unlearn.
Finally, I'd love to hear what you people do like about PErl OO and if there
are any good solutions for the issues I've raised apart from waiting for
Perl 6.
--
With kind regards Veli-Pekka Tätilä ([EMAIL PROTECTED])
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
