Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^4: Experimenting with Lvalue Subs

by BrowserUk (Pope)
on Jan 25, 2005 at 02:15 UTC ( #424771=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs

Which by the testimony of this thread will be as near useless and unuseable in P6 as they are in p5.


Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.


Comment on Re^4: Experimenting with Lvalue Subs
Download Code
Re^5: Experimenting with Lvalue Subs
by TimToady (Parson) on Jan 25, 2005 at 03:20 UTC
    Then the testimony of this thread is simply wrong. By explicit design, lvalue subs in Perl 6 will be just as usable as variables, which the testimony of this thread does not seem to understand are useful in many more places than just on one side of an = or the other. It's only the writing of lvalue subs that you're carping about, and that will definitely be easier in Perl 6 than in Perl 5. I see no new data here to warrant reopening the case.

      Then, with respect, I think that you and I are reading different threads.

      And that maybe you have missed all the discussion around the use of lvalue subs for accessors and mutators over the past 2 1/2 years. Literally every time the subject has come up, their use has been nearly universally rejected because of the absence of the ability to validate the assignment, without the resort to hookey, repetative and slow tieing of the underlying lvalue that is assigned. Every time.

      Even with the slightly streamlines syntax outlined in Apo6, it is still forcing the programmer to code additional and complicated code for every attribute of every class. Extra work in what will be the common case for--as best as I can tell--the purpose of avoiding it in the particular and less common case.

      For me, that renders the one feature of P6 that, aboe all others, I was looking forward to, almost useless. Better to stick with the current:

      sub getset { my self = shift; return $self->{thing} unless @_; die "Bad value" unless $_[0] =~ /valid/; $self->{thing} = $_[0]; }

      It's easier to code. Easier to read. Easier to debug. And probably quicker.

      I'll refrain from passing further comments on P6 related matters, because I think I just joined that band of people who will probably never use P6.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.

        What prevents you from writing, say, a Tie::IntRange class that constrains the values assigned to the scalar it ties, and reusing that code 1,500× for all your 1,500 attributes (with a different range declared in each instantiation of the tied class)? Or Tie::EnsureMatch which constrains the values assigned to the scalar it ties to those matching a particular regex supplied at instantiation time?

        This kind of reuse is really no different from what we already use Params::Validate for in another context.

        Makeshifts last the longest.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2014-09-03 03:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls