in reply to Re^3: why doesn't "my ($a,$b)" return a list?
in thread why doesn't "my ($a,$b)" return a list?

Well, my behaves different in several aspect to other buildins. For instance, it doesn't gobble up its arguments if there are no parens - but it does when there are. It also doesn't flatten its argument list. It also doesn't take just any expression as arguments, even though perldoc -f my suggests it does.

I find consider my to behave like a sub quite a stretch of my imagination.

Replies are listed 'Best First'.
Re^5: why doesn't "my ($a,$b)" return a list?
by ikegami (Patriarch) on Aug 19, 2010 at 18:11 UTC

    Well, my behaves different in several aspect to other buildins.

    A lot of builtins have unique parsing rules. (print, map, sort, system, our, ...) And?

    It also doesn't flatten its argument list.

    I don't see how you could pass something that could be flattened.

    I find consider my to behave like a sub quite a stretch of my imagination.

    Sure, typically my is typically used as a directive, but we're talking about using it inside an expression. I don't see any difference between

    foo(bar(ARGS)); foo(my(ARGS));

    Why do you think my should behave differently than bar?

      >> It also doesn't flatten its argument list.

      > I don't see how you could pass something that could be flattened.

      hmm  my (@a,$b,%h) behaves like a function with infinte prototype

      sub my (\[@$%];\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%] and so on )

      which avoids flattening.

      OTOH the lvalue character can't be simulated for more than one value.

      > > Well, my behaves different in several aspect to other buildins.

      > A lot of builtins have unique parsing rules. (print, map, sort, system, our, ...) And?

      The "And" is: If parsing rules are different, so why not the behaviour in scalar context, too?

      Cheers Rolf

        my (@a,$b,%h) behaves like a function with infinte prototype [(\[@$%];\[@$%]\[@$%]...]

        No references are taken. So that's both an inaccurate and a very complex way of thinking about it. It's much simpler to think of it as taking a list of variables.

        (That's why I didn't understanding what he meant by flattening: Nothing can be flattened into variables.)

        If parsing rules are different, so why not the behaviour in scalar context, too?

        It's possible. The parser converts qw( ... ) into a list. It could convert my (...) into a list of simple my expressions. In fact, it does that already, but it does it specially so the code behaves as if my was a function.

        But why would you want to make my() behave differently than foo(). That doesn't remove confusion or problems. It adds to them.

      I don't see any difference between
      foo(bar(ARGS)); foo(my(ARGS));
      But I do see the difference between
      bar(foo(ARGS)); my(foo(ARGS));
      Why do you think my should behave differently than bar?
      I've expressed no opinion on whether it should. I'm just observing it does.

        I've expressed no opinion on whether it should. I'm just observing it does.

        Please elaborate. So far, you've only given examples of how you can't use my. There's no disputing there are limits. You didn't give any example of how it doesn't behave like a sub.