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.
In reply to Re: attribute collisions Ãn Moose
by stvn
in thread attribute collisions ín Moose
by morgon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |