attribute collisions ín Moose

[morgon]

Hi,

I have a Moose-question:

Previously I have used Class::Std and one of the features I like about it is that there are not attribute-collisions betweeen a class and it's base-classes.

Now what happens in Moose when there are collisions? Let's try:

package Hubba;
use Moose;

has hubba => ( is => "rw", isa => "Int", builder => "hubba_builder1" )
+;

sub hubba_builder1 {
 return 1;
}

sub abba {
 my($this)=@_;

 return $this->hubba + 1;
}

This is a class that has an int-attribute "hubba" together with a builder and another method "abba" that uses that attribute. Now we add a collision:

package Bubba;
use Moose;

extends "Hubba";

has hubba => ( is => "rw", isa => "Str",  builder => "hubba_builder2" 
+);

sub hubba_builder2 {
 my($this)=@_;

 return "bubba";
}

So now we have a derived class that also uses a "hubba"-attribute but with a different builder and a different type.

The problem (at least I consider it a problem) now appears when we do this:

Hubba->new->abba;

Which in this example produces a warning as abba expects an int but gets a string.

Please forgive the clumsy example but the problem I see is this:

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. 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.

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?

Many thanks!

[stvn]

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.

[morgon]

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.

[stvn]

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.

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

[bruno]

First, a disclaimer: I am only speaking for my own experience, and could be totally wrong.

What I would do is use Moose's attribute extension capabilities. So, to sublclass Hubba with Bubba redefining the attribute hubba, I'd probably do:

package Bubba;
use Moose;

extends 'Hubba';

has '+hubba' => (
    is  => 'rw',
    isa => 'Str',
    builder => 'hubba_builder2',
);

sub hubba_builder2 {...}

Of course, you'd have to know beforehand that Hubba has the attribute hubba. In my experience, this has always been the case; I always know the parent class' API before subclassing.

[gwadej]

Although theoretically reasonable, this ability to have attributes (and/or methods) in a derived class completely different semantically than in the derived class is usually not very practical. As stvn points out, most OO developers aren't bothered by this lack.

I would go a bit further and say that any design based on this kind of feature is highly suspicious.

Contrary to what many people seem to have learned about OO, inheritance is an extremely strong form of coupling. You can't really ignore your base class while deriving. After all, by inheriting you are declaring that the derived class is just like the base class with a few extensions (or specializations). That is after all what an ISA relationship means.

Having a public attribute in a derived class that is radically different from the same named public attribute in the base class is a recipe for maintenance nightmares (he says from personal experience).

I am not (yet) a big user of Moose. But I've been doing OO in multiple languages for about 15 years. I have seen many systems that have tried to take advantage of this kind of feature over the years. Every single one of them was a source of ongoing bugs and pain.

I feel that if you find yourself in this position, the code is trying to tell you that you need to revisit your design.

[eric256]

I think you must have meant "Bubba->new->abba" produces the error. The below code works as I expect it to, printing 2 then your error, then 1.

#!/usr/bin/perl
use strict;
use warnings;

use Hubba;
use Bubba;

print Hubba->new->abba, "\n";
print Bubba->new->abba, "\n";

This makes sense to me because if i have code that is using a Hubba, and I make a Bubba, then that same code should be able to use the Bubba as if it is a Hubba, which means the interface shouldn't change. i.e. hubba is always an Int as the base clase says it should be.

[morgon]

I think you must have meant "Bubba->new->abba" produces the error.

Yes of course. Sorry for the typo.