Re: Class Attributes in roles?

forgive me for not quite understaning the intent of class_has but how
is this any diffrent from the code below? This already works:

#!/usr/bin/perl

use strict;
use warnings;
use Test::More qw{no_plan};

{
   package MY::Role;
   use Moose::Role;
   has bar => ( is => 'rw' );
}
{
   package MY::Obj;
   use Moose;
   with qw{ MY::Role };
   has foo => ( is => 'rw' );
}

my $c = MY::Obj->new(foo=>'hello', bar=>'world');
is ( $c->foo, 'hello' );
is ( $c->bar, 'world' );

=pod
ok 1
ok 2
1..2
=cut

On Wed, May 21, 2008 at 5:45 AM, Stevan Little
<[email protected]> wrote:
>
> 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
>
>
>
>
>
>



-- 
benh~