What are the drawbacks of autobox?

[LanX]

Hi

the very inventive modul autobox allows applying an OO Interface to the primitive datatypes in Perl 5, that means allowing to use it more or less in the (actually hyped) "Ruby way". (or long awaited Perl6)

The only caveats listed are that method calls in Perl are (of course) much slower ...

Autoboxing comes at a price. Calling

"Hello, world!"->length()

is slightly slower than the equivalent method call on a string-like object, and significantly slower than

length("Hello, world!")

Well, thats all? That OO is expensive is nothing new ...

Or are there any effects putting production code into danger? Couldn't find any corresponding discussion in the archives... hopefully this discussion is of general interest! 8)

[BrowserUk]

Can I turn your question around and ask what you see as the benefits of

my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();

versus:

my $error = abs( 3.1415927 - 22 / 7 );

[LanX]

UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)

hmm some brainstorming

• it's easier to read (and write)

   $ar->[$x][$y][$z]->push("element") than  push @{$ar->[$x][$y][$z]}, "element"

  The flow is in one left-to-right direction and doesn't jump around, the association is much more evident.

• this clear association make it much easier to parse (statically) and to design help systems in IDEs, interactively popping up the documentation for a method.

• method calls often allow cascading, like this enabling more expressive code.

• from a learners and documentation perspective its much easier to check the method of an object than browsing through docs to find the function and search what it does combined with a special datatype.

• it's easier to introspect (dynamically) which methods are possible for an object, even using a REPL which tab-expands to possible methods (that's really a powerful feature in the Python shell)

• Extending new methods which only work with special data-types (like adding ruby's each-behaviour to arrays) is easier and cleaner than prototyping a function each() ¹)

• it gets easier to port JS or Python code to Perl, strengthening the powerful future of our beloved language. ;)

• look at the arguments from the Perl6 designers ...

• TIMTOWTDI =)

  ¹) yes I know I could use "for", "each" was just an example, but please try to design a function which is restricted to arrayrefs, thats really far more complicated.

  UPDATE: corrected code and added further explanations in italics.

[BrowserUk]

it's easier to read (and write) $ar->[$x][$y][$z]->push("element") than push @{$ar->[$x][$y][$z]}, "element"

The basic programming 'association' as you term it is: $name = value;

And I think there is clarity in the mirrors: push @array, value; and push @{ <arrayRef> }, $value;.

The flow is in one left-to-right direction and doesn't jump around, the association is much more evident.

The left to right association of an array reference pushed onto an element?

I don't know of any language where the car->get's into->the man or the queue->joins->the boy are valid. Syntactically or semantically.

this clear association ...

I do not see this association you speak of, let alone clearly.

make it much easier to parse (statically) and to design help systems in IDEs, interactively popping up the documentation for a method.

Hm. So you consider making the language easier for the computer to parse, at the expense of making it harder for the human being, a benefit?

method calls often allow cascading, like this enabling more expressive code.

I'd really like to see you find a real live working example that demonstrates the use of cascading method calls. Once you find an example, we can then argue about how "expressive" it is.

For me, one of the many things I like about Perl is the wonderful expressiveness of the carefully tuned syntax. Making every operator a method call, is like fitting a tiller and anchor to your Fireblade.

it's easier to introspect (dynamically)

I absolutely challenge the need for dynamic introspection. Beyond your, REPL-prompts-the-programmer example, do you have a good example of when you might make use of this?

Extending new methods which only work with special data-types (like adding ruby's each-behaviour to arrays)

Is defining each() for arrays so hard? Or do you even need to do it at all:

map{ ... } @array;
... for @array;

sub each{
    my $code = shift;
    $code->( $_ ) for @_;
}

it gets easier to port JS or Ruby code to Perl,

That'd be a nice challenge. Pick a piece of published Ruby code, and you can port it with autobox and me without?

look at the arguments from the Perl6 designers ...

Only time will tell how well that works out in practice.

TIMTOWTDI =)

Actually, the underlying tenet of autobox is TIOOWTDI. Ie. The only operator allowed is ->.

JS, Ruby and even Smalltalk don't try and replace the normal math infix operators with a post-fix operator and verbose method names.

If you really want your 2009 cpu to run like a 1999 cpu, investigate:

use DB;
sub DB::db{ sleep 1 }

[Herkum]

While the language may seem clearer and in theory easier to understand, I find that it just syntax sugar candy. Looks tasty, but not does really provide anything.

Basically, if you want "Ruby" style code, then you can cut out the middle man and code in Ruby.

[dsheroh]

UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)

Erm... You do realize that my $error = 3.1415927->minus(22/7)->abs(); came straight from the autobox documentation (it's the second example under "SYNOPSIS"), don't you? It's not some fevered nightmare that BrowserUK dreamt up in an attempt to ridicule autobox, it's something that autobox's author put forward in a presumed attempt to show off how great it is.

[BrowserUk]

UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)

I just saw your above update. My only defense is that it is drawn directly from the second example given in the autobox POD.

I also saw your post, saying "how absurd this argument about Perl reflecting natural language is.".

It was you that suggested that array->push->element was somehow better than push array, element.

Another counter example is COBOL's MOVE value TO variable., though that's long been superceded by COMPUTE variable = expression;

[punkish]

not adding anything of value to this discussion other than to say, thanks for bringing autobox to my attention. I had no idea this existed. And, contrary to what others may think, I do find the ability to "turn everything into objects" very useful. It is not a matter of "if I want to code like Ruby then I should use Ruby." It is more like giving Perl the ability to program in a currently popular, and arguably easier, idiom of programming.

Look forward to more dissection and discussion of autobox.

[LanX]

> not adding anything of value to this discussion

Your plain wrong, you did! ;-)

I was recently complaining about many Pythonistas having this fundamentalist "There is only one true way to code and Guido is the prophet" attitude.

I was even claiming that the Perl crowd having more tolerance about paradigms, giving them the flexibility to adopt to new tasks...

Well ...maybe I wasn't completely wrong ... thanks! 8)

[dsheroh]

There's flexibility and there's following fads.

Show me a valid, real-world use case in which there is a significant advantage to treating the number 3 as an object rather than as a simple integer and I'm happy to be flexible and consider whether I would find a benefit in doing things that way. Until then, the idea that everything must be an object and all action should be expressible as method calls looks an awful lot like a fad to me.

[bruno]

Or are there any effects putting production code into danger?

I wouldn't say so. perl5i, which aims to be production-code material, has full autobox support.

One advantage of the "everything is an object" paradigm is the fact that namespace pollution is totally avoided. This allows to have many utility functions for each particular data structure type, without the danger of overcrowding the main namespace.

In perl5i, for instance, you can now do:

say "  this is some title.  "->trim->title_case;

# This Is Some Title.

or

my $paragraph = "Lorem Ipsum " x 90;

say $paragraph->wrap();

There are many more methods specific for arrays, hashes, code references, etc. This wouldn't be practical without this paradigm, as it would quickly pile up into having either long and awkard function names to prevent collision (hi PHP!), or avoiding having them altogether.

At first, as many people here, I was skeptical as to the usefulness of it. After playing with this for a couple of days, I found that it can indeed be quite useful, and sometimes it also reads more naturally. YMMV.

[LanX]

Bruno, many thanks for pointing me to perl5i! =)

I'll give it a try!

(but I certainly will have to thoroughly analyze how autobox works before I take it into production! )