in reply to Re: OO in Perl 5: still inadequate
in thread OO in Perl 5: still inadequate

You can’t use phrases like “on par” and “inadequate” without also explaining your metric.

I did lay out the metric; that’s what the post was about.

So, who should win?

What I am after will offend some people’s sense of beauty, but works out favourably on all other metrics, near as I can tell. Which is just why I want it.

In my experience, no level of language enforcement stops bugs.

I’m not looking for enforcement – I said as much in the post, right? I want encapsulation to be the default situation, but not the only one. I want to be able to write a subclass without worrying about what any superclass is doing under the covers, because I’m secure in the knowledge that if I don’t go rooting around for anyone’s underwear, I won’t run into it. It’s the same principle as global variables.

Just wait to the dumb kids start using Ruby to see a lot of bad Ruby code.

This the exact point I made in an article on lesscode.org.

I don’t mind that Perl allows people to break encapsulation.

I would mind if it didn’t. (Ruby allows it too, for that matter.)

That some people can do bad things doesn’t convince me that I should give up using Data::Dumper on an object without creating an as_dumped_string method in every class.

Precisely. And more to the point, being able to break encapsulation allows abstractions that are impossible in a language with enforced encapsulation. And that, I really care about. A tool with which you can’t do any damage is worthless.

I’m not asking for strong encapsulation, I am after an OO approach where isolation is the default, so I won’t have to worry about accidentally breaking superclass code, just because I decided to use a private instance variable that happens to be named the same as a private instance variable in one of the superclasses.

Hence “advisory encapsulation.”

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^3: OO in Perl 5: still inadequate
by brian_d_foy (Abbot) on Jan 21, 2006 at 17:01 UTC

    By metric, you have to explain how you measure adequacy. You haven't done that. If you meanto imply that adequacy is completely measured by encapsulation then the argument is quite silly.

    I'm not arguing with you about encapsulation. I think you missed the point about OO programming by arguing that you can't do it adequately in Perl.

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
[reply]

      The metric is: is there a way which keeps my subclass a) isolated and encapsulated from any implementation details of the superclass b) while later letting me break this subclasses’ encapsulation iff I so choose? I explained how the approaches known so far fail to satisfy this metric. (Except I missed the fact that xdg pointed out.)

      Ruby offers that, which is why I said Perl 5 is not on par with it. (Turns out it is.)

      Makeshifts last the longest.

[reply]

        That's the single measurement that makes Perl 5 OO inadequate? Nothing else matters? That's the only thing you are going to use when you compare other languages?

        Perhaps you should have chosen a better title for your node: "Perl OO encapsulation inadequate", because that's all you're talking about and its a very poor judge of a language's adequacy. Your claims that Perl is deficient come without anything Perl doesn't allow us to do or a way in which it fails to help us get work done.

        I think, then, that I'd have to put your argument in the category of "mathematical purity wanking" because you haven't shown any inadequacy in any other dimensions I explained in my original reply. In everyday life, this issue is something far down on the list of things people care about.

        As I said earlier, there are better things to argue about if you want to call Perl's OO inadequate. A better start is Perl's lack of objects. :)

        --
        brian d foy <brian@stonehenge.com>
        Subscribe to The Perl Review
[reply]

In Section Meditations