in reply to 5.10 smart match behaviour

Is this a constraint of some sort or a plain bug ?

The table in the docs1 describing the match behaviour doesn't say anything specific about what the operator does if either side is a list, or how exactly it would treat the return value of a (constant) function... In other words, I wouldn't call it a bug. OTOH, you're not the first to be struck by this somewhat non-DWIM behaviour, and probably not the last...

(Personally, I'd find it more intuitive too, if a list would work like an array in the context of the smart match operator... but I don't know if it's too late to make that change now — or what other reasons there might have been to want it behave the way it's currently implemented.)

___

1 search for "Smart matching in detail" (unfortunately there's no respective anchor in that doc, so I can't link to it directly)

Replies are listed 'Best First'.
Re^2: 5.10 smart match behaviour
by Fletch (Bishop) on Jun 10, 2008 at 13:41 UTC

    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.

[reply]
[d/l]
[select]
      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]

In Section Seekers of Perl Wisdom