Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^4: What are the drawbacks of autobox?

by chromatic (Archbishop)
on Feb 28, 2010 at 21:38 UTC ( [id://825782]=note: print w/replies, xml ) Need Help??


in reply to Re^3: What are the drawbacks of autobox?
in thread What are the drawbacks of autobox?

I find that it just syntax sugar candy.

Be careful; this argument slides down a slippery slope to "Everything's just NAND gates anyway!"

The fact that you don't have to worry about an (artificial) distinction between non-object primitives and your own objects and types in terms of polymorphism and genericity is a huge advantage of autobox. Whether that advantage is practically realizable is a matter of opinion, but it's a potential benefit.

  • Comment on Re^4: What are the drawbacks of autobox?

Replies are listed 'Best First'.
Re^5: What are the drawbacks of autobox?
by Herkum (Parson) on Mar 01, 2010 at 20:02 UTC

    I think the issue I have is that it is not really solving anything. It is just using different syntax to do the same thing that can already be done. That was the whole point behind Ruby, someone wanted different syntax for doing the same thing. I fail to see the benefit of trying to make Perl act like Ruby.

    I also don't see a huge advantage of autobox just because it distinguish between objects and non-objects and can apply generic method calls. So what; Java does this as well and Java is not any better for it.

    I keep thinking of autobox being a lot like Louisiana Creole, French and English mixed together to form something that no one outside of Louisiana can understand it.

      ... it distinguish between objects and non-objects and can apply generic method calls. So what; Java does this as well and Java is not any better for it.

      Java doesn't do this; that's one of the most persistent (and damning) criticisms of Java's design.

      I think the issue I have is that it is not really solving anything.

      Have you ever written code that has to figure out whether you have a scalar, a scalar reference, an array reference, a hash reference, a class name, an object, a tied variable, a reference blessed into a class but treatable as an opaque object and not a reference type?

      Have you ever written code with the simple precondition that one of its arguments must somehow stringify sanely -- you don't care how it does that, merely that it does that -- but the mechanism for type checking in Perl 5 is so disjointed and bicameral that it's almost impossible to write a check that's both correct and not so strict that it prevents useful (and common) behavior?

      Have you ever thought to yourself "Self, tie would be so much more useful if it weren't a righteous pain to use!" or "I like the idea of overload, but ... wow, what a mess!"?

      I've done all three.

      I fail to see the benefit of trying to make Perl act like Ruby.

      I fail to see the problem of borrowing good ideas from other languages (and you mean Smalltalk, not Ruby) if they solve very real, very painful problems in an elegant way.

      If you have a criticism of autobox better reasoned than "If you want to use Ruby, you know where to find it!" I'm happy to discuss that... but Perl 5's primitive obsession extrudes from the VM level and makes things like tie unnecessarily complex. Major credit should go to chocolateboy for creating something which people can experiment with to discover how the language could look without the historical baggage of implementation.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2024-04-19 07:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found