perl_oop_restrictions

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
From: Piers Cawley <pdcawley@bofh.org.uk>
Date: 07 Dec 2000 12:30:59 +0000

Robin Berjon <robin@knowscape.com> writes:

> At 14:07 06/12/2000 -0500, kyle dawkins wrote:
> >Ok, you're missing my point but that's partially my fault for not explaining. 
> > First, let me agree:  Java's "everything is an object" mentality sucks 
> >balls.  And yes, Perl's duality of functional/OO is really nice.  Taking that 
> >away is not what I am advocating... I think there should be the *option* in 
> >Perl to disable certain features that make Perl a dangerous language for OO 
> >development.  First and foremost, the lack of true encapsulation is 
> >disastrous.  There is no concept of private data because instance data is 
> >stored in a blessed hash (typically) that's open wide to the world.  It makes 
> >it tough to create a true interface/implementation dichotomy that is 
> >important in the OO world.

I've got the beginnings of an interface/implementation thing going
with Perl 5, check out ex::implements and ex::interface. They're still
not 100% there because I haven't actually written any real
documentation, and there can be problems with pre existing AUTOLOADs
for the non 'utterly strict' version, but there's the beginnings of
something decent. At least you now get an error thrown at compile time
if you haven't actually implemented everything you promised to
implement.

But until 'my Dog $spot' becomes an assertion that $spot can only be
either undefined, or something that implements the 'Dog' interface, my
code is just an experiment. Albeit a possibly useful one.

> That's because of the way most people implement their classes. Perl does
> have a concept of private date (although it's not built into the language
> as that) and it's actually fairly easy to get that. OO Programming with
> Perl by Damian Conway has plenty of example demonstrating that. 

All hail Class::Contract. Slow as a dog 'cos of all the tie magic, but
*utterly* fantastic otherwise. Again, fingers crossed for Perl 6
making 'tie' or its moral equivalent nice and fast. 

And there's so much in Perl that makes OO so *nice*. For instance, I
have a container class (It's a row in a shopping basket) that can be
fully specced completely independently of the stuff it contains and
yet, because of AUTOLOAD and 'can' it can present itself as if it were
the contained object to stuff that is expecting that. Which reminds
me, I really need to overload the container's 'isa' method so that it
can return true to C<$container->isa('Contained')>. 

But then another problem arises: Because C<{}->isa(...)> throws an
exception, too much code ends up doing C<UNIVERSAL::isa($foo, 'Bar')>.
Good, friendly polymorphic behaviour would have
C<$unblessed_ref->isa(...)> and C<$unblessed_ref->can(...)> returning
sensible values. Some sort of $random_ref->is_blessed() method might
be handy too.

And here we are, too late for a perl6.language rfc...

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu