Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI )

by educated_foo (Vicar)
on Dec 13, 2013 at 23:11 UTC ( [id://1067083]=note: print w/replies, xml ) Need Help??


in reply to Re: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI )
in thread Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ;)

I agree, but to be slightly more constructive...

A truly "flexible" solution would be to use the existing function call syntax, but extend it to call methods. (You can do this now with a UNIVERSAL::AUTOLOAD override, though that's fiddly and slow.) Writing foo($x,$y) as $x->foo($y) makes the first argument look special, where it is not for functions and multi-methods. Common Lisp got this right.

Replies are listed 'Best First'.
Re^3: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI )
by LanX (Saint) on Dec 14, 2013 at 01:36 UTC
    > but to be slightly more constructive...

    indeed! =)

    > Writing foo($x,$y) as $x->foo($y) makes the first argument look special, where it is not for functions and multi-methods.

    How is the first argument not special in the shown examples?

    For instance does push @a, 3 change the first parameter.

    Equally the ->cycle() example.

    And how is the bind operator matches= $x=~ /regex/ not special in Perl? Is it really better than @matches = $x->match(/regex/) ?

    Though I agree that something like $y= $x->plus(5) breaks symmetry, but thats not my intention.

    So in short: I think your critic doesn't apply to mutators, where the first arg IS special.

    Additionally in cases where dereferencing is needed, this can significantly simplify the syntax (multiple nested curlies around HoAoH do not facilitate readability)

    Anyway I don't claim it to be a full replacement of real autoboxing, holding the method in $variable namespace is - well - not "optimal".

    And the fact that only scalars are allowed on LHS is also a limitation!

    I hope it's obvious that "Yes we can!" and "How I finally learned to love ..." were ironic references.

    I wanted to share and discuss this idiom, but I don't expect a Nobel prize for coolness like Obama or consider me half as genius as Dr Strangelove...

    In this sense Hail! Mr President! xD

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    update

    > Common Lisp got this right.

    Could you plz elaborate, I don't know Common Lisp, (only eLISP¹)!

    Something like wrapper functions which check the type of the first argument (ref) and call a method based on their own name (caller) are no problem in Perl.

    footnotes

    ¹) mentioned to please Your Mother :)

      (Slightly delayed response...)
      I think your critic doesn't apply to mutators, where the first arg IS special.
      I hadn't really thought of it this way, since $x->y(...) is proposed to be used in so many other ways (e.g. @array->grep(/blah/)). This almost makes me want to propose an $x op= ... syntax to make the intent explicit, but that way lies pain and bike-shedding.
      Additionally in cases where dereferencing is needed,
      As long as this doesn't violate the basic Perl principle that operators determine operand type, it's fine -- I have no problem with auto-deref.
      Could you plz elaborate, I don't know Common Lisp, (only eLISP¹)?
      As a fellow Elisp user and Emacs lover...

      In Common Lisp, a function call always looks like (NAME ARG...). So x = y is (setq x y) (or (set (quote x) y). When they added "OO", they kept that syntax, so $x->f(...) became (f $x ...). But they did better: if the meaning of "f" depended upon more than its first argument (like addition, or exponentiation, or some comparisons), then it still used (f ...) syntax, but let the programmer specify rules to decide what to do based on any subset of the parameters.

      Of course, this being Lisp, it became something hairy, but see "CLOS" for the details.

        > then it still used (f ...) syntax, but let the programmer specify rules to decide what to do based on any subset of the parameters.

        multimethods?

        > I have no problem with auto-deref.

        one of the peculiar sides of Perl is that plenty of build-ins internally work on references and but force you to dereference the argument manually.

        Furthermore since map and grep operate on lists and return lists it's not trivial to define other functional constructs which only operate on refs.

        For instance a function keygrep {... } %hash isn't very clever, since %hash is listified, OTOH keygrep { } $href breaks the symmetry and can't be recombinded with map / grep (at least on the RHS).

        Now a method could easily fill this niche by operating on _refs_ and returning _refs_ :

        $href->keygrep(/.../)->map(\&func)->grep(/.../)

        Maybe not easy to explain, but this caused me many headaches in the past...

        Cheers Rolf

        ( addicted to the Perl Programming Language)

Re^3: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI )
by BrowserUk (Patriarch) on Dec 14, 2013 at 09:13 UTC
    I agree, but to be slightly more constructive...

    Having shown the "reasoning" given in the OP is a total logical fallacy, there is no foundation upon which to construct anything positive. Further comment would be unchivalrous.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-03-28 13:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found