in reply to attribute collisions ín Moose

I (up to now) have held the conviction that you should be able to derive from a class without knowing it's implementation (or attribute-list) and by deriving you should not break base-class functionality but this does not be possible in Moose.

In an ideal world, that would be a worthy conviction to hold. But reality is such that you very rarely can treat an object you are subclassing as a opaque black box. In languages like Java/C#/C++ where you have strong privacy it is possible to get much closer to this ideal because you can hide attributes/methods from your subclasses. But Perl has no notion of privacy (and Moose will never add support for it) and all methods in Perl are virtual methods, the combination of these two things mean that opaque black boxes are not easily accomplished.

But don't despair, this is not really that bad a thing (your "Intro to OOP 101" professor who put this conviction in your head might disagree, but he is not here to help you now) and millions of Perl, Python, Ruby, Lua, Javascript, etc., etc. programmers have written billions (perhaps trillions) of lines of OOP code quite successfully.

As I have tried to show above a class that derives from a base-class but accidentaly uses an attribute with the same name as one of the parent-classes not only shadows the parent-class attribute but completely replaces it, thereby possibly damaging base-class methods.

Well, the issue I have with that is that both the hubba attribute and the hubba_builder1 builder method are public (privacy in perl is not enforced with code, but instead by the leading underscore convention). Even in an ideal world when you override public methods, ... well,... you override public methods. Which means it did *exactly* what you asked it to do. Of course (as I pointed out above) all methods in Perl are virtual, so even if you followed the leading underscore convention of privacy you could still introduce a conflict.

Now, while you could argue that this is annoying and wrong, it is also how Perl has worked for many years so would not be surprising to many a seasoned Perl OO programmer.

So below the line it looks to me that whenever I use Moose and want to derive from a class I have to manually ensure that there are no attribute-collision - or am I doing something wrong?

No, your not doing anything wrong. You should (always) at the very least check to make sure your not accidently overriding a public method or public attribute of your superclass, this should be enough in 90% of the cases you will encounter. If you find that you are doing a lot of private methods or attributes (again using the leading underscore convention) then you probably want to just double check to make sure your not also overriding them in your superclass. Of course a simple and pretty good way to avoid this is to make sure your private methods/attribute are named in such a way that they will not easily get overridden. Personally I just tend to name them very verbosely and in 10+ years (7 of which were using OO Perl, but all of which were doing OOP in some kind of dynamic language) I have maybe run into this problem 4 or 5 times.

-stvn

Replies are listed 'Best First'.
Re^2: attribute collisions ín Moose
by morgon (Priest) on Apr 14, 2009 at 13:34 UTC
    your "Intro to OOP 101" professor who put this conviction in your head

    Unfortunately (or fortunately?) I never studied Computer Science (only Math) - but I have to admit that my thinking about OO is heavily influenced by Bertrand Meyer.

    But I hope my posting is not misunderstood:
    It is not intended to denigrate Moose in any way - in fact I like it a lot, so thanks for all the effort you've put into it.

      Unfortunately (or fortunately?) I never studied Computer Science (only Math)

      Me either, I studied Fine Arts Painting, but never finished. CS degrees can be overrated especially since the course material is typically out of date shortly after it is written, such is the nature of our industry.

      but I have to admit that my thinking about OO is heavily influenced by Bertrand Meyer.

      Ah-ha! I should have known, your comments made me think of Eiffel actually. I am a big fan of Mr. Meyer (in fact, Reusable Software : The Base Object-Oriented Component Libraries is one of my favorite books) but he is very much an purist and so should be taken with a grain of salt. I mean, after all the guy actually designed the Eiffel language for the book, because he felt the other OO languages were not sufficient to get across his vision of OO purity*.

      But I hope my posting is not misunderstood

      Not at all, sorry if my response lead you to believe that.

      -stvn

      * - at least this is what I have read, it may just only be rumor.