|Pathologically Eclectic Rubbish Lister|
Re^8: Class::Accessor and Damian's PBPby nothingmuch (Priest)
|on Feb 24, 2006 at 13:34 UTC||Need Help??|
The interesting thing is called rhethorics, and also i asked what is the point of your discussion, and then criticized not it's point, but it's conclusion.
Well, no, I don't care what you do, I just don't want the OP to get the impression that this is the simplest way to do it, or the one that is almost universally accepted by the Perl community.
It's like people don't recommend writing XS code to do a simple task that pure perl is universally accepted for. Now, your perspective seems to be "take the word universally with a grain of salt, because TIMTOWTDI", but the way you recommend is really counter productive.
Essentially the tied variable approach means: move the accessor to a format where behind the scenes every property is really an object pretending to be a perl variable (by conforming to an interface), that is magically bound to a real perl variable, that also contains storage space, and has a single mutator named STORE, and a single accessor named FETCH, both of which will be called automatically when the Perl builtin assignment is being made. I think this is bad advice, because it improves nothing over the accessors are smelly point you made earlier, but introduces action at a distance, the requirement to understand how tying works, what lvalue methods are, to know that this accessor is an lvalue (and thus to have to appropriately to use it as such), in addition to the property oriented interface that you criticized.
I am criticizing the Lvalue approach because it does not solve the problem you stated, and in addition I'm also criticizing your original criticism, because it's off topic (which is generally fine, but you should at least provide good advice), and generally not the way things are done in the perl world for cultural and code reuse reasons. I could have counter pointed saying TooManyMethodsCodeSmell, arguing that if an object knows to do anything it's a god object, instead of just a simple property. If we had that CPAN would be unusable. But I did not, despite this being my opinion because I really don't care. The reason I did criticize your point was that you provided bad advice to as a solution to the problem, which is twice as bad because it doesn't even solve this problem.
If you do it in your own code - whatever. But please don't recommend to others to use these things too. What diotalevi said basically sums it up - Perl's support for lvalue accessors is weak. Your retort to that is "but we have enough hooks to unweaken it". My counter retort to that is that reccomending weird hacks to work around language limitations instead of solving the problem in a syntactically different (perhaps even inferior) way is bad advice. Furthermore, quoting a discussion as if it's a reference (c2.com) and using that to rationalize your misleading argument is also a bad thing, in my opinion.
zz zZ Z Z #!perl