Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by boftx (Chaplain)
on Dec 14, 2013 at 04:05 UTC ( #1067102=note: print w/ replies, xml ) Need Help??


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

Someone much wiser than me once said it is better to remain silent and be thought a fool than to open one's mouth and remove all doubt.

That being said ... I feel compelled to ask the (obvious?) question of what does this buy us? To me, it looks a lot like using postfix notation in a way that does not contribute to making Perl read like English. That is, where next unless $foo > $bar; reads like a sentence in English, @foo->push($bar) doesn't, to me at least. (I should point out that I take strong exception to PBP discouraging postfix notation.)

I think my point can be demonstrated even better when given something like 'Hello, world!'->upper();. There is no need whatsoever for an argument to "upper" in that case. How is that more clear as to intent than upper('Hello, world!');? (I will grant that a modification-in-place such as $foo->upper() might be more concise that $foo = upper($foo), but clarity would still be open to debate, especially given a use-case such as say $foo->upper();.)

I can see where this could be useful for a language that is not as flexible or useful as Perl (i.e. strongly typed languages that resemble a straight-jacket) but I don't see that it adds to Perl other than contributing to (excessive?) code bloat in an effort to add something that Perl might not really need given its existing versatility.

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.


Comment on Re: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ;)
Select or Download Code
Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ;) (passive voice)
by LanX (Canon) on Dec 14, 2013 at 06:45 UTC
    > what does this buy us?

    What does it cost us?

    For me the method notation is an _alternative_ not an obligation (TIMTOWTDI).

    YMMV and I'm not radical about it.

    I don't wanna repeat all given arguments in details, so just telegram style:

    • autoboxing allows a method API at primitive types, that is normal operations like ++ have no speed penalty.
    • avoid multiple parens, e.g for dereferencing like @{ ...}
    • readability! With 2 arguments the methodname and not a comma separates in between like a binary operator  xxxxx->push yyyyy
    • in deeply nested datastructures the operation is written next to the addressed element
    • ease of porting from other languages
    • no need for prototypes
    • mutators highlight the changed argument on LHS

    I agree that upper $foo is easier than $foo->$upper but I personally prefer

    $personal{Berlin}{employee}[9]{name}->$upper to see that the name is uppercased.

    and better $personal{Berlin}{employee}->length() than scalar @{ $personal{Berlin}{employee} }

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    update

    > reads like a sentence in English,

    After some meditation, I realize that many exceptions to "reads naturally" rule in Perl are just ignored, which cause a logical break.

    For instance nobody says

    "rewrite from personal in Berlin which is employee of Number 9 the name".

    rewrite( $personal{Berlin}{employee}[9]{name} )

    You rather say "rewrite the name of the 9th employee in the Berlin catalog of employees"

    The problem is that nested data structures are top-down, but we can't code

    rewrite {name}<-[9]<-{employee}<-{Berlin}<-$personal

    (well we could, but how likely is that to be implemented?)

    OTOH human language is flexible enough to use a passive voice construct

    "From the catalog of Berlin the employee number 9's name has to be (or is) rewritten."

    $personal{Berlin}{employee}[9]{name}->rewrite()

    I hope you get the point, with deeply nested top-down data structures a method call helps to put the verb near the subject.

    Just read methods as passive constructs.

Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ;)
by taint (Chaplain) on Dec 14, 2013 at 07:08 UTC
    Greetings boftx.

    While I completely see, and can agree on your point. I think it exemplifies Perl's ability to cater to some areas (or edge cases) that any other language wouldn't even consider making possible. But maybe that's because it's an "interpreted" language? Dunno. I'll really need to ponder that more. But initially, that's my take on it. And let us not forget; Wall was trained as a linguist, and the design of Perl is very much informed by linguistic principles.

    Say what you will about programing languages. But if there's any comparison to the spoken language, if I've learned anything. I've learned, it's all a matter of interpretation -- what's one to one, is something completely different, to another. Or, in other terms; TMTOWTDI ;)

    No disrespect intended. Just my take on it. :)

    --Chris

    Yes. What say about me, is true.
    
Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ;)
by LanX (Canon) on Dec 16, 2013 at 12:33 UTC
    My last answer was more about the general properties of method-syntax.

    But there is also a very specific Perl issue, which became clearer after playing around.

    Perl has a syntactical ambiguity between scalars and one element lists.

    So writing something like $ref->functionality clearly operates on the referenced elements while  functionality $ref might operate on the "listed" reference itself.

    Methodcall gives us an opportunity to add new flavors of grep which operate on references without the need to rename it grepref.

    Think of a hashgrep which could be written  $href->grep sub { $_->key =~ /x/ }

    (the need to write sub is due to another syntactic ambiguity: "block" vs "literal hash")

    background

    For instance it's not trivial/possible to augment the classical

     grep BLOCK  LIST

    to also mean

     grep BLOCK AREF

    Because it's not possible to rule out that  grep {...} $aref means "operate on the list with the one element $aref".

    Languages where "everything is an object/reference" w/o lists don't have this abiguity.

    They need workarounds for lists, for instance do some JS dialects introduce list-assignments by using array syntax:

     [a,b] = [b,a] ;// swap elements Mozilla JS 1.7

    Cheers Rolf

    ( addicted to the Perl Programming Language)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2014-10-02 03:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (45 votes), past polls