Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re^8: Class::Accessor and Damian's PBP

by nothingmuch (Priest)
on Feb 24, 2006 at 13:34 UTC ( #532535=note: print w/replies, xml ) Need Help??

in reply to Re^7: Class::Accessor and Damian's PBP
in thread Class::Accessor and Damian's PBP

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 ( and using that to rationalize your misleading argument is also a bad thing, in my opinion.

zz zZ Z Z #!perl

Replies are listed 'Best First'.
Re^9: Class::Accessor and Damian's PBP
by Roy Johnson (Monsignor) on Feb 24, 2006 at 15:22 UTC
    I am criticizing the Lvalue approach because it does not solve the problem you stated
    I didn't offer it as a solution to having a lot of accessors. What I offered as a solution to that was that the OP re-examine his approach. It would be impossible to suggest anything more specific, because we don't know what the requirements of the task are.

    Then I started a new paragraph to address a different issue that the OP wanted to address: that there be a clear syntactic distinction between set and get, so that setting isn't done by mistake. Lvalues do make that distinction clear.

    If you do it in your own code - whatever. But please don't recommend to others to use these things too.
    I recommend that others look at the various options available to them and make their own decisions. If they find your arguments compelling, that's great. But they shouldn't be browbeaten into following your approach, or Damien's, or mine. It is NOT true that they absolutely must value simplicity of implementation (a lower level of abstraction) over elegance of interface (a higher level of abstraction). That is a trade-off that might have different "right" answers depending on the target user and usage.

    Your complaints about "weird hacks" are irrelevant. Those are implementation details, and the user need not be concerned about them. The user is concerned about a usable interface and performance, and sometimes there are trade-offs in one to improve the other.

    Caution: Contents may have been coded under pressure.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://532535]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (1)
As of 2021-04-17 04:34 GMT
Find Nodes?
    Voting Booth?

    No recent polls found