If I misunderstood you -- correct me. It seems that all you worry
about is that you want some variable be seen in several subroutines
.. you propose a mechanism of passing them between desired subroutins
by default through all the dynamical chain of sub calls "connecting
them. It seems , on the other hand , that there is already existing
and ( to my taste ) simpler mechanism of making several subroutines (
and in general -- any lexical scopes ) share *the same* variable --
package ... ;
sub a { our $x is private ; ... } ; #...but see below ...
sub b { our $x is private ; ... } ;
so $x is *package* variable that can be seen *only* from "a" and "b".
it plays the role of "mailbox" : "a" can put there whatever it want to
pass to "b" . "b" should know about it ( and it knows because it
declares $x inside its body ) and should fetch whatever it wants.
it seems that this mechanism is cleaner and clearer and .. more
intuitive.
although...
on the second thought I have a feeling that I am pulling "is private"
property too much -- this way of using it was not discussed in Exe3.
so probably we should invent the property that does exactly that :
this variable is package *but* it is seen only from *several* lexical
scopes , something like this :
package ... ;
sub a { our $x is shared ; ... } ;
sub b { our $x is shared ; ... } ;
we can even prescribe which lexical scope is allowed to change it :
package ... ;
sub a { our $x is shared is rw; ... } ;
sub b { our $x is shared is ro; ... } ;
but maybe this is abuse for rw and ro here -- so this should be
package ... ;
sub a { our $x is shared(rw) ; ... } ;
sub b { our $x is shared(ro) ; ... } ;
also there is one thing that bothers me about even the original "is
private" property : what if my package is *really big* and I have in
two distant places two function that each want its own "static"
variable that they declare as Exe3 prescribe as
our $var is private;
but since I dont remember about having two such subs I can happen to
give them the same name - so that naively they will be aliased to the
same package variable . Now, with "is private" that is , probably not
a problem , because compiler can notice this and complain about it .
but If I want to pull similar mechanism for *sharing* variables --
this becomes a problem -- compiler cannot know that I wanted to share
one variable $x between aub A and sub B and *another* variable (
which I mistakenly called $x too ) between sub C and sub D . In this
case it will share $x between *all four* subs. I dont know how to
stop this source of errors . currently . but anyway that is what
bothered me with "is private" property.
anyway, my feeling is that once it is necessary to pass variable far
enough it is clearer to do it with globals -- which are restricted to
be seen only in the restricted set of lexical scopes.
arcadi .
Me writes:
> In summary, I am proposing that one marks
> variables that are to be automatically
> passed from sub to sub with 'is yours'
> where appropriate.
>
> An example of what I'm suggesting follows.
> Code with brief comments first then explanation.
>
> {
> my $_; # $_ can't be touched
> # unless it is passed
> # to a sub explicitly.
>
> my $foo; # same for $foo
>
> my $baz is yours; # $baz will automatically
> $baz = 10; # be passed to /directly/
> # called subs that "ask"
> # explicitly for $baz.
>
> &waldo($foo);
> }
>
> sub waldo ($b ; $baz is yours)
> { print $baz; &emer; }
>
> sub emer (;$baz is yours(no))
> { print $baz; &qux; }
>
> sub qux { ... }
>
> Running this prints '1010'. Here's why:
>
> A property exists that can mark any lexical
> as "yours". When a variable is marked yours
> it is automatically passed to any directly
> called sub (not nested subs) that mentions
> it appropriately.
>
> The "automatic" $_ (available without
> declaring with a 'my') is marked "yours"
> by default.
>
> All other (ie declared) lexicals are, by
> default, not yours, hence guaranteed to be
> private lexicals unless explicitly passed
> to a sub. This is safer than the current
> perl 6 design in which use of $CALLER::,
> and even builtins and subs that merely
> use the topic, might accidentally clobber
> one of my lexicals at any time.
>
> Once execution reaches the body of waldo,
> there is a new lexical called $baz that is
> bound to the lexical with the same name in
> the body of the caller.
>
> The C<is yours> in waldo's sig has two
> effects:
>
> 1. It requires that any /caller/ has a
> variable of the same name marked as
> yours or must pass a variable/value
> using the named arg syntax for that
> arg name;
>
> 2. It propogates the marking of $baz as
> a yours marked variable for any sub
> called from this, the body of waldo.
>
> Once execution reaches the body of emer,
> there is a new lexical called $baz that is
> bound to the lexical from waldo which is in
> turn bound to the lexical within qux.
>
> The '(no)' at the end of the C<is yours>
> means that $baz is private to emer -- it
> will not be passed to called subs by the
> yours mechanism.
>
> In summary, you mark variables that are
> to be automatically passed from sub to
> sub with 'is yours' where appropriate.
>
> --
> ralph
>
>
