Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: Perl 5 OOP solutions

by stvn (Monsignor)
on Apr 14, 2006 at 21:38 UTC ( [id://543441]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Perl 5 OOP solutions
in thread Perl 5 OOP solutions

You are absolutely correct that Moose and Class::MOP both do not attempt to change the underlying fundementals of Perl 5 00, it attempts to augment them in such a way that all the (sometimes dangerous) flexibility is retained and all the tedious repitition is removed. To address the quote the OP gave:

This is quick and easy, but it has encapsulation, substitutability, and namespace clashing problems.
The need for strong encapsulation is (IMO) overblown. In many of the application domains where perl thrives, it is not really needed, and if you do find you really need it, you probably shouldn't be coding in Perl anyway. Of course encapsulation has a social component to it as well, a "keep out the dumb programmer next to me" feature. But honestly, I think that issue is better addressed by social policy than by language features.

As for substitutability, a well designed class will not have this problem. In fact I can break substitutability in just about any language, although languages with strict type systems are harder than dynamic languages like Perl/Python/Ruby/etc. A well designed class hierarchy will not break substitutability, a language compiler/runtime which double checks that for you is nice at times and restrictive at others.

The "namespace clashing" is a little ambiguous, it sounds to me like a C++ism and really just another word for encapsulation. In that case, my above comment applies.

So all that said, you can see why i did not try to address these items with Moose and Class::MOP, I don't see them as dire problems. The dire problems I see with Perl 5 OO is the tediousness manual nature of it. Too often I find myself writing the same code over and over. Things like constructors, slot creation and initialization, accessor methods, the list goes on and on. Solutions like Class::Accessor, Class::MethodMaker, etc. only address certain issues and either don't handle the others, or worse, handle them poorly. I do not think this is a failing of these modules (or their authors), but a failing of Perl's OO facilities in general. In short, it's extreme flexibility makes enforcing consistency difficult, and without some consistency these problems cannot be solved. The primary goal of Class::MOP is to create a meta-level infrastructure which can serve as that layer of consistency, while trying to not enforce that consistency on the user (non-meta) level.

Now, some people might not see that tedium I mention as being nearly as important as things like encapsulation. I disagree, reducing tedious and repetitive coding means reduced errors. And not logic errors, but stupid errors, silly ones that you can spend hours trying to hunt down cause you wouldn't think to look in that tedious repetitive code you have written 1000 times. And all that tedium usually means duplication, which is where simple typing errors and misspellings can easily creep in. If you only ever write the name of your attribute once (in it's attribute definition) and the meta-level handles things like slot initialization, accessor generation, etc., simple spelling errors then become much less common.

But enough babbling, let me address some of your comments:

And while it might be possible to build inside-out objects using Class::MOP, the InsideOutClass example bundled with it has substantial missing pieces and is currently YABIOOI (yet another broken inside-out object implementation). When I have enough tuits, I might tackle a proper inside-out implementation using Class::MOP.
I am sure It is quite broken, but it is mearly a proof of concept for alternate instance storage schemes, and not meant ever to be used seriously. The missing piece are left as an exercise to the reader *cough* hint hint *cough* ;)
I'm glad to see some of the insights from the Perl 6 object system migrating back to Perl 5, but I don't think that Class::MOP or Moose really address the underlying issues that the OP was asking about -- though they do bring some useful systematization to Perl OO techniques and make it easier to address the problems that exist today.
Actually, my point above is that a "useful systematization to Perl OO techniques" actually can go a long way to solve the underlying issues the OP is talking about. Of course YMMV and TIMTOWTDI.
For that matter, it should be noted that inside-out objects aren't a panacea, either. They solve a couple of problems, but at the cost of a substantial increase in complexity.
I actually think that a meta-level infrastructure like Class::MOP might be just what inside-out objects need to help reduce that complexity. By moving the complexity up the meta-chain, you move it out of the view of the casual user, and still keep it accessible to those who need it.

-stvn

Replies are listed 'Best First'.
Re^4: Perl 5 OOP solutions
by chromatic (Archbishop) on Apr 14, 2006 at 22:24 UTC
    The need for strong encapsulation is (IMO) overblown.

    I'm pretty sure I wrote the article to which the OP refers (What is Perl 6) and what I meant is that unencapsulated access to attributes in a parent class outside of pure accessors dictates the implementation of descendent classes.

    Try subclassing IO::Handle sometime.

    I don't particularly care if it's possible for someone clever or committed or crazy to do bad things with the internals of my objects with reflection or XS or ugly hacks. I do care if I have to work around someone else's poor implementation choices because of bad defaults.

    Stronger encapsulation keeps the details of the implementation of a class behind an interface, where it belongs.

Re^4: Perl 5 OOP solutions
by xdg (Monsignor) on Apr 15, 2006 at 13:11 UTC
    The need for strong encapsulation is (IMO) overblown. In many of the application domains where perl thrives, it is not really needed, and if you do find you really need it, you probably shouldn't be coding in Perl anyway. Of course encapsulation has a social component to it as well, a "keep out the dumb programmer next to me" feature. But honestly, I think that issue is better addressed by social policy than by language features.

    The point I make in my Inside-Out tutorial presentation is that people frequently mistake encapsulation for hiding information. I see encapsulation as insulating users and subclassers of a class from its implementation. Social policy can work within a team, but it doesn't help when Module::X on CPAN that you subclass suddenly switches from hash-based to array-based (or inside-out) implementation.

    As for substitutability, a well designed class will not have this problem. In fact I can break substitutability in just about any language, although languages with strict type systems are harder than dynamic languages like Perl/Python/Ruby/etc.

    I see this as more related to the first point. Consider all the mess that UNIVERSAL::can/isa play with things like Class::Adapter -- substitutability needs to be at the interface level, not the blessed or reftype level.

    The "namespace clashing" is a little ambiguous, it sounds to me like a C++ism and really just another word for encapsulation.

    Yes and no. Within Perl and in reference to hash-based objects, I think this refers to how keys within a blessed hash can clash between super/subclasses. That is an encapsulation issue, but the way it crops up even without changing the type of the blessed reference is very specific to the history of how objects are created in Perl.

    I actually think that a meta-level infrastructure like Class::MOP might be just what inside-out objects need to help reduce that complexity. By moving the complexity up the meta-chain, you move it out of the view of the casual user, and still keep it accessible to those who need it.

    I need to understand Class::MOP and how it's used for Moose much better, but from what I saw in trying to understand Moose's capabilities, I have a sneaking suspicion that it might be possible to wrap Class::MOP around Class::InsideOut without too great a struggle. (Things like serialization might become interesting.)

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://543441]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-03-29 06:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found