|
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:
- It could require that its peer use well-known names for any state and/or methods that it needs to access.
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.
- It might be possible to it by introspection.
Though it would still need to know what methods to look for, so I see no advantage in that.
- Or the using class could provide either names or references (delegates) to the Role's constructor.
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.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|
Re^4: Some thoughts on Moose Attributes
by stvn (Monsignor) on May 02, 2011 at 01:50 UTC
|
As you've probably worked out by now, I'm not, nor ever likely to be, a Moose user.
Holy Crap! Really!!! Now it all makes sense! ;)
But I'm not critical of Moose.
Kinda, sorta, not really. But that is okay, we can take it, nothing should ever be above criticism. Perl is built on the foundation of TIMTOWTDI, which means that the language itself is flexible and can very easily be different things for different people.
| [reply] |
|
|
Kinda, sorta, not really.
Yes, really.
Some people swear by DBIx::Class &| Class::DBI. Others have fundamental issues with the entire concept of such tools. Both factions coexists and even cooperate.
That's how I see Moose. I have a problem with its conception, but I recognise that many people do not share that. I also recognise that of its type, it is absolutely the best of breed. I see the stability it has. I see the dedicated support you give it.
And for those that need or want (or simply don't yet know what they need or want in this regard), I heartily recommend Moose to them.
Why do I respond in threads regarding Moose.
In part, because I wish to understand what other people are getting from Moose.
But also, because Moose questions tend to relate directly to the fundamentals of object orientation itself.
It will probably surprise some when I say that I happen to think that OO is the single, most powerful concept to arise in programming. Ever. Full stop.
But I don't want it as a monoculture. And I think that there is a lot of 'bad OO' around. I also think that bad OO is (far) worse than bad procedural. And possibly, though I haven;t made up my mind, worse than bad functional. If I have an agenda, it is simply that I wish to express my thoughts on what makes some common OO practices good, and others bad. And to receive feedback and counter opinion so as to refine my opinion.
However, if you would rather that I stayed out of Moose threads and never mention the M-word again, then I will understand that and be gone.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
However, if you would rather that I stayed out of Moose threads and never mention the M-word again, then I will understand that and be gone.
Never,... never ever, ... never ever, ever would I say that. I may not (or ever) agree with you on the specifics, but I appreciate fully your input. Keep on keepin' on brother!
That said, I do love messing with you. If ever you are at a YAPC::NA, PPW or OPW, all your beers are on me :)
Love and kisses,
| [reply] |
|
|
Re: "Why do I respond in threads regarding Moose. "
Don't forget too, that I learn more from heretics than from the brainwashed yes-men.
Re: "And I think that there is a lot of 'bad OO' around."
Back in the early '90,s when all the hype was on OO and the "paradigm shift", I suggested, just to be contrary, an article for Ed Yordon's "American Programmer" on "The Dark Side of OOP". He didn't take it as a joke, and asked me to submit the article.
| [reply] |
|
|
|
|
Re^4: Some thoughts on Moose Attributes
by John M. Dlugosz (Monsignor) on May 02, 2011 at 02:03 UTC
|
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.
I recall in the earlier days of Perl 5 there was an array-based mechanism added that pre-compiled the slot names into indexes. That was indeed faster, but it was deprecated and removed due to some issues I've forgotten.
There may be more experiments later, with Perl-6 lust and current work in moving parts of Moose to XS. Abstraction opens up all possibilities.
| [reply] |
|
|
The simple fact is, looking up the address of a method, even with catching--without yet invooking it--is no faster than a hash lookup. That's because it *is* as hash lookup.
And then you have to invoke it. And then it has to refernce the attribute through some mechanism. And then it has to return it.
So, you have 'a hash lookup' versus 'a hash lookup, plus invocation, plus whatever mechanism to obtain the attribute value, plus the return'.
It doesn't matter what happens inside the accessor to obtain the value, you've already lost by the time you looked up the address of the method. From that point on it is all down hill.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re^4: Some thoughts on Moose Attributes
by John M. Dlugosz (Monsignor) on May 02, 2011 at 01:58 UTC
|
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 was thinking more along the lines of intrinsic support, using a mechanism like Perl 6. But furthermore it might be available on some platforms and not others, or use XS to backport some of the higher stuff to other versions so the same support _seems_ to be there but is not as snappy.
Maybe I'll load a Perl 5 Moose-based module into a Perl 6 program.
| [reply] |
Re^4: Some thoughts on Moose Attributes
by John M. Dlugosz (Monsignor) on May 02, 2011 at 02:16 UTC
|
You digressed a bit to talk about Roles...that could be a new topic. I know Roles (in the abstract sense) quite a lot better than I do about Moose. One of the things you mentioned makes me ponder a bit, but my meditation queue is a bit long already.
(I've also noticed how delegation makes aggregation much cleaner to use. So... if the Role doesn't mess with the containing object, just use delegation and containment. Using 'handles' you have the clean syntax without mentioning the composited object.)
Why am I likely to remain a Moose user?
For the same reason that Perl's best feature is CPAN; Moose has "community support". It does do things for me that I've gotten benefit from, and many new features and different ways of approaching things is already published and ready to reuse.
Also, major packages like Catalyst and FormFu are Moose-ified, so if I will monkey around with those I need to know what I'm doing.
So, you didn't comment on the second of my ponderables: can Moose live with direct access to state as hash elements of $self? | [reply] |
|
|
So, you didn't comment on the second of my ponderables: can Moose live with direct access to state as hash elements of $self?
Hm. The simple answer is: I don't know.
The more thoughtful answer is, if I am not going to use the generated accessors; and I see no use for the introspection, what would I get from Moose?
It cannot generate my non-accessor methods for me, so nothing to gain there.
And one of Moose' strongest features is that it will inter-operate, subclass and superclass, bog standard blessed ref classes. So, I don't need to use Moose in order to benefit from existing moose-based modules.
At that point, your ponderable becomes a moot issue. (For me.)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
