Author: sorear Date: 2010-07-03 06:39:32 +0200 (Sat, 03 Jul 2010) New Revision: 31532
Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] Clarify interaction of lexical classes and packages with members after discussion with TimToady Modified: docs/Perl6/Spec/S04-control.pod =================================================================== --- docs/Perl6/Spec/S04-control.pod 2010-07-02 23:37:35 UTC (rev 31531) +++ docs/Perl6/Spec/S04-control.pod 2010-07-03 04:39:32 UTC (rev 31532) @@ -1625,7 +1625,7 @@ no guarantee can be made that the scope needed for cloning will remain in existence over the life of the reference.) -In particular, named subroutines are a special problem when embedded in +In particular, package subroutines are a special problem when embedded in a changing lexical scope (when they make reference to it). The binding of such a definition to a name within a symbol table counts as taking a reference, so at compile time there is an initial binding @@ -1642,6 +1642,21 @@ take into consideration that it is functioning only as a cache of the most recent cloning, not as a surrogate for the current lexical scope.) +Matters are more complicated if the package in question is lexically defined. +In such cases, the package must be cloned as if it were a sub on entry to the +corresponding lexical scope. All runtime instances of a single package +declaration share the same set of compile-time declared functions, however, +the runtime instances can have different lexical environments as described in +the preceding paragraph. If multiple conflicting definitons of a sub exist +for the same compile-time package, an error condition exists and behavior is +not specified for Perl 6.0. + +Methods in classes behave functionally like package subroutines, and have the +same binding behavior if the classes are cloned. Note that a class declaration, +even an augment, is fundamentally a compile-time operation; composition only +happens once and the results are recorded in the prototype class. Runtime +typological manipulations are limited to reseating C<OUTER::> scopes of methods. + Lexical names do not share this problem, since the symbol goes out of scope synchronously with its usage. Unlike global subs, they do not need a compile-time binding, but like global subs,
