ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Paul Kulchenko                       2:5020/400     20 Apr 2000  20:07:03
 To : All
 Subject : Re: mod_perl
 -------------------------------------------------------------------------------- 
 

 Hi, Dmitriy!
 Dmitriy Goldobin wrote in message <8dmv4j$m13$1@www.office.ems.chel.su>...
 
 >> В пределах модуля да. Hо Apache::Registry скрипт не является модулем.
 >> Он является телом процедуры.
 >Тогда почему BEGIN{} допускают к переменным тела процедуры? Если бы
 
 Потому что это обычная (почти) функция. И правила видимости для нее те же.
 Только вызывается автоматически.
 
 >BEGIN ругнулся на неопределенную переменную было бы понятнее.
 
 Так она определена. Hо имеет неопределенное значение. :)
 
 perlsub.pod
 
 Just because a lexical variable is lexically (also called statically)
 scoped to its enclosing block, C<eval>, or C<do> FILE, this doesn't mean
 that
 within a function it works like a C static.  It normally works more
 like a C auto, but with implicit garbage collection.
 
 Unlike local variables in C or C++, Perl's lexical variables don't
 necessarily get recycled just because their scope has exited.
 If something more permanent is still aware of the lexical, it will
 stick around.  So long as something else references a lexical, that
 lexical won't be freed--which is as it should be.  You wouldn't want
 memory being free until you were done using it, or kept around once you
 were done.  Automatic garbage collection takes care of this for you.
 
 This means that you can pass back or save away references to lexical
 variables, whereas to return a pointer to a C auto is a grave error.
 It also gives us a way to simulate C's function statics.  Here's a
 mechanism for giving a function private variables with both lexical
 scoping and a static lifetime.  If you do want to create something like
 C's static variables, just enclose the whole function in an extra block,
 and put the static variable outside the function but in the block.
 
     {
  my $secret_val = 0;
  sub gimme_another {
      return ++$secret_val;
  }
     }
     # $secret_val now becomes unreachable by the outside
     # world, but retains its value between calls to gimme_another
 
 If this function is being sourced in from a separate file
 via C<require> or C<use>, then this is probably just fine.  If it's
 all in the main program, you'll need to arrange for the C<my()>
 to be executed early, either by putting the whole block above
 your main program, or more likely, placing merely a C<BEGIN>
 sub around it to make sure it gets executed before your program
 starts to run:
 
     sub BEGIN {
  my $secret_val = 0;
  sub gimme_another {
      return ++$secret_val;
  }
     }
 
 See L<perlmod/"Package Constructors and Destructors"> about the C<BEGIN>
 function.
 
 If declared at the outermost scope, the file scope, then lexicals work
 someone like C's file statics.  They are available to all functions in
 that same file declared below them, but are inaccessible from outside of
 the file.  This is sometimes used in modules to create private variables
 for the whole module.
 
 Т.е. ожидается "If declared at the outermost scope, the file scope, then
 lexicals work
 someone like C's file statics.", но из-за того, что mod_perl меняет область
 видимости, получается:
 "It normally works more like a C auto, but with implicit garbage
 collection."
 
 Если модифицировать пример:
 
 sub a {
   my $secret_val = 0;
   sub gimme_another {
     ++$secret_val; print "plus $secret_val\n"; return $secret_val;
   }
   print "a $secret_val\n";
 }
 
 a;
 gimme_another;
 gimme_another;
 a;
 gimme_another;
 
 То увидим, что после выполнения у нас имеются две переменные $secret_val: на
 одну ссылается gimme_another а другая используется в a.
 
 Best wishes, Paul.
 --- ifmail v.2.15dev4
  * Origin: Gamma NNTP server Moscow Russia (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор