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

[educated_foo]

(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.

[LanX]

> 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...

[educated_foo]

multimethods?

Just some more terminology. A "method" is &{lookup($x, 'name')}($x, ...). A "multimethod" is just &{lookup($x, ..., 'name')}($x, ...)).

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.

each() *once* only worked on hashes, so it could complain at compile-time. Now it not only works on hashes and hash-refs, but also on arrays and array-refs, so if it gets a reference, it has to either guess (i.e. DWIM) or, in the current implementation, complain and refuse to do anything useful (i.e. "Type of argument to each on reference must be unblessed hashref or arrayref").

[LanX]

> each()  once only worked on hashes,

true, never thought about it, but each can handle such problems only at runtime now.

So do you like or dislike it?

I mean, we could drop the new behavior in favor of method-calls on scalars... ;-)

update

oh just noticed again, you alread said

> no problem with auto-deref.