Re: Class Attributes in roles?

On May 20, 2008, at 8:53 PM, Ricardo SIGNES wrote:
> * Stevan Little <[email protected]> [2008-05-20T09:47:17]
>> On May 19, 2008, at 8:30 PM, Bernardo Rechea wrote:
>>> Grr, It would be quite a learning curve before I would able to  
>>> understand
>>> Moose well enough to even try... Do you think at least that  
>>> having class
>>> attributes declared in roles is reasonable?
>>
>> No, I don't think it is reasonable.
>>
>> Class attributes are really attributes of the metaclass instance  
>> (Dave
>> implements them slightly differently then that, but the effect is the
>> same). When a role is composed into a class, Moose will merge all the
>> attributes and methods defined in the role into the class. It does  
>> not
>> however merge all the attributes and methods from the metarole  
>> into the
>> metaclass.
>
> This sounds, to me, like an argument from implementation, instead  
> of from first
> principles.
>
> Is this statement true, outside the realm of how things are  
> implemented:
>
>   A role, when applied to a class, affects the behavior of  
> instances, and only
>   of instances?
>
> I don't think it is, because it may add class methods.

Well the argument *could* be made that class methods and class  
attributes are different, but then you can start getting into the  
"objects are the poor mans closures" stuff and this isn't  
comp.lang.lisp and I really don't want to go there anyway (so instead  
I just point to it as I drive by :P).

Anyway, yes, it is somewhat implementation dependent (although it is  
not entirely true, cause there is no reason Dave can't add this  
feature, although it would be kinda tricky), but it also theoretical  
too.

A truely *pure* object system would not have classes at all, a class  
would itself be just an *instance* of $Class which itself would be an  
instance of $Class (http://www.iinteractive.com/moose/images/ 
class_mop_model.jpg). In that sense, you don't ever distinguish the  
difference between class and instance data, it is just obvious that  
"class" data is means instance data in the metaclass.

I try to mimic this in Class::MOP as best I can, but in order to make  
it useable and not full of AUTOLOAD crack, it has to bind itself to  
the Perl notion of packages, classes and blessed instances. Once I  
have the ability to overload -> (*wink*) then I can abandon the  
(broken) packages == classes idea and be able to implement that more  
pure system I speak about above (*cough* Moose 2.0 *cough*).

> Now, I know that this may be a bit of a lame argument, since Perl  
> is so lousy
> about distinguishing class and instance methods, so I will not  
> insert a
> dramatic sting and an "AHA!" here.  I just think that it's one bit  
> of evidence
> that roles affect class behavior as well as instance behavior.

> If that's the case, class attributes should be able to be provided  
> by a role.

Hmm, not sure that the argument for adding a feature should be "so  
that it can match the other broken features" :P

> If they can't be, then I could imagine myself very soon wanting to  
> start using
> a lot more factory objects, which would be annoying.


My personal feeling is that class level data and methods are bad, and  
that they should generally be avoided in a design. Quite often a  
Singleton or even just a regular old instance will be enough to  
replace that need. Of course, this is *my* approach and TIMTOWTDI so  
feel free to ignore.

As for the "can this be done", yes it can, but currently we do not  
have an easy way to hook into role composition to add features like  
this into roles. This feature is on the TODO list (nothingmuch wanted  
it recently for something), so we could use this as the impetus to  
get this started (although tuits are somewhat in short supply for  
nothingmuch and I because of $work).

- Stevan