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.
| [reply] |
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.
| [reply] |
... 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.
| [reply] |
Well I brought a list of arguments and you answer with your personal "findings"?
>While the language may seem clearer and in theory easier to understand, ...
Wasn't "make frequent things easy to code" a Perl mantra?
> Basically, if you want "Ruby" style code, then you can cut out the middle man and code in Ruby.
Silly me, and I thought TIMTOWTDI is Perl's style to code... ;-)
I'm curious what would your answer become if I edit my posts to s/Ruby/Perl6/g ?
BTW your not answering the OP about autobox and I never propagated that others should code this way!
| [reply] |
One thing that most people forget is that TIMTOWTDI doesn't mean "There Is More Than One Way To Do It". It means "There Is More Than One Way To Do It (but most of them are wrong)".
| [reply] |
| [reply] |
