in reply to Re^2: Some thoughts on Moose Attributes
in thread Some thoughts on Moose Attributes
In Perl 5.xx+ maybe an efficient XS-based slot mechanism will be added to some platforms, and my existing classes and most of CPAN and all the Catalyst stuff should just work and suddenly work faster! So, maybe I want to keep my options open just now.
Hm. That seems like a prime example of the whatifitis I've been decrying elsewhere :)
Without claiming any great expertise in XS, the idea that calling an XS subroutine to access a variable could ever be quicker than a direct hash element look up doesn't seem at all feasible, let alone likely.
I guess using internal accessors would (in Perl) facilitate changing the blessed reference type from hashref to arrayref. Or possibly vice versa, though a reason for doing the latter doesn't instantly spring to mind. But the main reason for switching from a hashref to an arrayref is performance. Array lookups using constant subs is a tad quicker than hash lookups.
But if performance is the reason for the change, then you'd achieve greater gains by dropping the accessor methods and going direct to the hash.
The only other reason I can think of for why you might consider the switch from hashrefs to arrayrefs is to reduce storage requirements. But if you have a class that has sufficient instance attributes to make that switch significant on a per-instance basis, then there is something cock-eyed with your design anyway. And if you are using sufficient individual instances of a given class to make the combined storage requirements of the instances worth switching, then you should be using an aggregate rather than individual instances anyway.
So, maybe you and I would both like a lvalue option.
The only half-good reason (that I can see) for using lavlue accessors for private attributes is the simplified syntax. $self->x++; is nicer than $self->{x}++; or $self->[X]++;.
And for non-performance critical classes that would, indeed has been, sufficient reason for me to use lvalue methods.
Now roles on the other hand can be added to any kind of class, and can't assume the storage layer in use by whatever class it winds up in. So it should be more abstract, unless it's app-specific and knows something about where it's going.
My thought processes come a little unstuck when it comes to Roles. Basically, I haven't used them.
The main disadvantage of composition relative to inheritance is that where the latter allows $self->superclassMethod();, the former requires $self->{compositeObject}->method();.
I mostly see Roles as a way of avoiding inheritance whilst avoiding the double indirection required by composition. In that scenario, the internals of the Roles class are (by my rules) entirely transparent to and inaccessible from the incorporating class. That is, there doesn't seem much point in incorporating a Role into a class, if the class needs to manipulate the attributes within the Role directly, The class might just as well declare an instance and manipulate it. The Role needs to provide methods that do things to or with the state they incorporate, otherwise there is little purpose in them.
And that brings me to the thorny issue of the Role operating not on its own internal state, but rather on the attributes of the class into which it is incorporated. This, on the surface at least, appears to be a useful possibility.
And as far as I can see, there are 3 ways a Role could be written to have access to its peers attributes:
Whilst simple to implement, it seems that this would be a particularly crude way to go about it. Whatever names were chosen might make sense in terms of the generic Role, but no sense at all in terms of the classes that use that Role. It is easy to see that a method provided by a Role might have a positive connotation in one calling class but a negative connotation in another. And if the Role specifies a neutral 'well-known name' then you end up with the worst of all worlds where it makes no sense in the contexts of either type of using class.
Though it would still need to know what methods to look for, so I see no advantage in that.
This seems to be the 'best' method (I can think of), but do Roles have constructors?
As you can probably tell, I'm not really up with how Roles are actually implemented. Or used for that matter. I did start to look into their implementation in Moose once a while ago, but the complexity left me cold. Not so much that I couldn't follow it through all the layers--though it was definitely tough going in several places. Mostly, I just got disheartened to see just how much complexity was involved to achieve something that I can implement myself using standard Perl in a couple of dozen lines.
As you've probably worked out by now, I'm not, nor ever likely to be, a Moose user. But I'm not critical of Moose. If you need its facilities, or can llve with its costs for your application, then it is an absolutely amazing piece of work with some major benefits, especially for Perl/OO beginners.
I just don't happen to fit into any of those categories.
|
|---|