Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

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

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


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

Except you have to create a convoluted mess of tying a variable and returning it in a way that is both hard to read and hard to maintain, at the dubious benefit of having sugar that is not socially acceptable *ANYWAY* in perl today.

What is the point of your discussion? Are you proposing to revise the currently unversally accepted style? Because Perl 6 is already doing that and it will look like you want it to look, except it won't be insane.

If you are trying to fix the accessor code smell (Which is moot in my opinion - accessors are necessary for storing data in a data oriented culture like perl whether the smalltalk heads like it or not) by abusing weird perl features is IMHO not going to give you any less code smell, but actually more (IntentionNotAlgorithm, KeepItSimpleStupid, YouAren'tGonnaNeedIt, FeatureCreep).

Punchline: you're proposing to simplify by making it more complex. That's wrong. I think that this is MentalMasturbation.

-nuffin
zz zZ Z Z #!perl


Comment on Re^6: Class::Accessor and Damian's PBP
Re^7: Class::Accessor and Damian's PBP
by Roy Johnson (Monsignor) on Feb 24, 2006 at 12:40 UTC
    What is the point of your discussion? ...
    If you are trying to fix the accessor code smell ...
    Punchline: you're proposing to simplify by making it more complex.
    So you don't know what I'm trying to do for most of your post, but suddenly in the last paragraph, you decide you do know. That's very interesting.

    No, I wasn't trying to fix the accessor code smell, and no, I wasn't proposing to simplify. I was merely expressing my own preference for a different style. There is no single universally accepted style. There really is more than one way to do it, and it's not wrong.

    I think that this is MentalMasturbation.
    And your post is what? Warning me that I'll grow hair on my mental palms and go blind?

    Caution: Contents may have been coded under pressure.
      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.

      -nuffin
      zz zZ Z Z #!perl
        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?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-12-26 12:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls