ts <decoux / moulon.inra.fr> wrote:
>
> >>>>> "L" == Leo Razoumov <see_signature / 127.0.0.1> writes:
>
>L> I do not understand why "my" is too complex to a user. It has been in 
>Perl for
>L> years and no one complained of its complexity.
>
>  OK, explain me this result
>
>pigeon% cat a.pl
>#!/usr/bin/perl -wl
>use strict;
>sub toto
>{
>     my $i = shift;
>     my $m = $i if !($i % 5);
>     $m++;
>     print "$i : $m";
>}
>
>for (my $i = 0; $i < 15; $i++) {
>     toto($i);
>}

Ah, my favorite bug!

The implementation of my in Perl has a stupid optimization.
Perl allocates space for the my once, and then reuses the
space later, depending on a runtime initialization to know
whether it needs to reinitialization.  With the one line
conditional it may skip this needed initialization, leading
to the value from a previous call being preserved.

Perl actually keeps track of the number of times a function
has been called and keeps separate stacks for each.  Which
means that deep recursion in Perl permanently ties up memory
and makes Perl look very bad on certain benchmarks.  The
interactions of this bug and that behaviour can lead to very
odd results.

It has been known for years (having been discovered in turn
by at least 3 people) and deliberately not documented.  It
has become much better known in the last year since one Ben
Tilly set down to figure out why the Number::Format module
had a particular bug, discovered this feature, and then went
on to complain quite bitterly about it.

I would clearly not suggest that Ruby implement this
feature with this buggy optimization.  And since the
structure of a scalar in Ruby is much smaller and cleaner
than a scalar in Perl there is little reason to want to do
this.  I note that this bug is very Perl specific and in
Lisp, for instance, there is no corresponding problem.

And so I still absolutely think you are wrong that it is
bad to have the concept of being able to say that this,
here, is a private variable that shall forevermore be
private no matter what else is in scope.  An example why not
having it is a bad idea, when constructing strings or blocks
that will be evalled in someone else's context, it is good
for both you and them that you have the ability to within
this section declare certain variables as private to your
code and be able to limit how you will interact with their
code without having to examine it.

Absolutely none of the examples that you have presented has
shaken my belief that private temporary variables, a concept
that is available in most decent languages, would be an
unnecessary obfuscation in Ruby.  I use them religiously
when they are available.  It is true that 99% of the time
they accomplish absolutely nothing, but I am glad that I will
never find out which 1% of the time I saved myself a nasty
headache...

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com