Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

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

by Roy Johnson (Monsignor)
on Feb 23, 2006 at 17:40 UTC ( #532337=note: print w/replies, xml ) Need Help??

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

That's exactly equivalent to overriding the STORE method for a tied variable. Advantage: none.

Caution: Contents may have been coded under pressure.

Replies are listed 'Best First'.
Re^6: Class::Accessor and Damian's PBP
by nothingmuch (Priest) on Feb 24, 2006 at 00:00 UTC
    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.

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

        zz zZ Z Z #!perl

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2023-03-20 18:23 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (59 votes). Check out past polls.