Re^2: 5.10 smart match behaviour

And it would magically determine whether to call an arbitrary function between list and scalar contexts how . . . ?

As has been pointed out, it's a binary operator ~~(albeit a two-character-wide one)~~ just like + so the operands are put in scalar context just like every other binary operator. If you want it to work as if called on an array(ref), explicitly provide it with one by wrapping with []. Otherwise you're creating an exception for this one op and breaking orthagonality.

Update: Someone mentioned that there's other two-character-wide binary ops, and you know actually most of them are two chars. /me needs more caffeine . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re^2: 5.10 smart match behaviour Select or Download Code

Replies are listed 'Best First'.
Re^3: 5.10 smart match behaviour by almut (Canon) on Jun 10, 2008 at 14:58 UTC
As has been pointed out, it's a binary operator (...) I know it is a binary operator, and I personally do know how to handle that... I'm just saying that it might be more intuitive if it would default to a (more DWIM) list context interpretation instead... (I bet this very problem is going to be a recurring issue here at PM). I so far haven't seen a convincing argument why it couldn't - in theory - behave that way ("not breaking orthogonality" is not sufficiently convincing, IMHO). A lot in Perl is concerned with making code do what people expect. And after all, there are other builtins, and at least one operator that can deal with lists just fine (think of `(1, 2, 3) x 5`). Sure, changing things will create conflicts with respect to the currently documented behaviour, but I wonder if it's primarily those scalar context variants that people will be thinking of using the smart match operator for, or if it's more the particularly neat implicit iteration behaviour that people will predominantly be wanting to use this operator for. In the latter case, it would be more natural if it could deal with lists without any special ado... Just my five cents. (Ultimately, what's intuitive and what isn't is mostly an empirical or statistical question, so maybe we should have a PM poll on that?)	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: 5.10 smart match behaviour
by almut (Canon) on Jun 10, 2008 at 14:58 UTC

As has been pointed out, it's a binary operator (...)

I know it is a binary operator, and I personally do know how to handle that... I'm just saying that it might be more intuitive if it would default to a (more DWIM) list context interpretation instead... (I bet this very problem is going to be a recurring issue here at PM).

I so far haven't seen a convincing argument why it couldn't - in theory - behave that way ("not breaking orthogonality" is not sufficiently convincing, IMHO). A lot in Perl is concerned with making code do what people expect. And after all, there are other builtins, and at least one operator that can deal with lists just fine (think of (1, 2, 3) x 5).

Sure, changing things will create conflicts with respect to the currently documented behaviour, but I wonder if it's primarily those scalar context variants that people will be thinking of using the smart match operator for, or if it's more the particularly neat implicit iteration behaviour that people will predominantly be wanting to use this operator for. In the latter case, it would be more natural if it could deal with lists without any special ado... Just my five cents.

(Ultimately, what's intuitive and what isn't is mostly an empirical or statistical question, so maybe we should have a PM poll on that?)

[reply]
[d/l]