Branden wrote:
> 
> As to the second item b), I would say I withdraw my complaints about `my' if
> my other proposal of `use scope' gets approved (since then I don't need `my'
> anymore!). I guess I would be happier with `use scope', and I also think it
> would make you happier, since it wouldn't bother the current way `my' works,
> and all you'd have to do is not bothering the `scope' pragma exists.

I wouldn't be so hasty to withdraw from the my binding argument. There's
many uses of "my" that are required even with the "use scope" pragma (at
least as I described it in RFC 64, but feel free to point it out if I
missed an application). I think there's some good chugging on the my
binding concept going on, so let's not kill it quite yet.

To rehash, all this discussion should involve is the possibility of
making "my" swallow its list args:

   my $x, $y, $z;   # same as  my($x, $y, $z)

That's it. No changing the way lists and , and = work in Perl. If you
want to use split you still have to say:

   my($name, $passwd) = split ':';

As far as I can tell, these are the current arguments for/against my
being changed to bind less tightly:

   FOR
   ---
     1. It becomes more consistent with other Perl functions

     2. It makes certain uses easier to write and understand,
        such as when declaring lots of variables on the same
        line. Many expect this:

             my $x, $y, $z;

        to DWIM.

   AGAINST
   -------
     1. This is a change that will make mixing type declarations
        in the same line of code harder to do, such as:

           (my $x, our $y) = @_;

     2. In certain situations, such as trying to declare a variable
        inline as a list arg, it requires an extra set of ()'s.
        For example:

            tie my $shoe, $string;
   
        no longer works as written, since my will gobble the vars
        and tie will complain "not enough arguments".

        Once point of consideration: What if my() returned its
        argument list verbatim, similar to how bless() does
        double-duty?

     3. This is a change which will break existing Perl code.


Although overall I support the "FOR" (I think?), those are some pretty
big "AGAINST" arguments that we need to consider.

-Nate

Reply via email to