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

My point was that my, our and state aren't subs but operators and shouldn't be handled as subs.

The named operators (my, print, substr, time, etc) are just like subs in many regards, to the point of being called (builtin) functions.

my happens to have a compile-time effect, but it still behaves like a sub at run-time.

Replies are listed 'Best First'.
Re^4: why doesn't "my ($a,$b)" return a list?
by LanX (Saint) on Aug 19, 2010 at 16:02 UTC
    It might be handy and orthogonal to implement my as a function, but I dare to question this design decision.

    I can't possibly imagine any use of calling my in scalar context, since the list must be statically fixed at compile time.

    Furthermore it's not intuitive, if shortening the number of my's result in these side effects. I searched for an hour to find the problem...

    Perl already has the disadvantage to default to global vars while other languages automatically restrict to a local scope without extra operator...

    ... one shouldn't be punished for trying to economize keystrokes!

    Anyway it's too late... but IMHO at least a warning should be emitted when using a my(LIST) in scalar context.

    Cheers Rolf

[reply]
[d/l]

      I can't possibly imagine any use of calling my in scalar context

      if (my $x = ...) { ... }
open(my $fh, ...)
read(..., my $buf, ...)
my $r = \my $s;

      [download]

      Perl already has the disadvantage to default to global vars while other languages automatically restrict to a local scope

      What language are you talking about? C, C++, Java, JavaScript and VB all require local declarations.

      a warning should be emitted when using a my(LIST) in scalar context.

      More precisely, my LIST with a list of more than one variables.

      Because of its side-effects, my LIST could legitimately be used in scalar context. This job may be more appropriate for a linter (Perl::Critic). But since that use is rare and easy to rewrite (into something clearer), a warning could be appropriate. Feel free to create a ticket (just need to email perlbug@perl.org).

      I only looked quickly, but my and friends might be the only builtins to return something of questionable use in scalar context.

[reply]
[d/l]
[select]
        > What language are you talking about? C, C++, Java, JavaScript and VB all require local declarations.

        The direct competitors, Python and Ruby, but with the restriction of function-scope instead of block-scope. And PHP ¹)

        JS is very strange in this respect, requiring explicit declarations with "var" but only allowing function-scope.

        Newer JS (Mozilla) Versions have "let" which corresponds to "my" in Perl.

        > More precisely, my LIST with a list of more than one variables.

        exactly!

        Cheers Rolf

        1) updated

[reply]
Re^4: why doesn't "my ($a,$b)" return a list?
by JavaFan (Canon) on Aug 19, 2010 at 17:41 UTC
    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.

[reply]
[d/l]
[select]

      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));

      [download]

      Why do you think my should behave differently than bar?

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

[reply]
[d/l]
[select]
        I don't see any difference between 
        foo(bar(ARGS));
foo(my(ARGS));

        [download]
        But I do see the difference between 
        bar(foo(ARGS));
my(foo(ARGS));

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

In Section Seekers of Perl Wisdom