> you propose a mechanism of passing [vars] > between desired subroutins by default > through all the dynamical chain of sub > calls "connecting them.
There's more, or rather, less to it than that. The same mechanism also includes a clean way to pass "it", something that needs to be done. And a way to smoothly extend that for user defined "pronouns" like $first, $rest and $last, through to mini-vocabularies like $source, $target, $user, ... (Imagine you pull in fop1, fop2, fop3 that are file ops written by three independent authors that just agreed to conventions on naming args. With the mechanism I propose you can now do something like: my $source, $target, $user; ... fop1; fop2; fop3; To get this sort of simplicity, you have to decouple inter-sub interfaces in a couple ways, including arg positions and package names.) So I'm addressing several idioms that range from passing one or two pronouns around in the local vicinity, between a caller and a called sub, to passing a whole suite of values (an "environment") to an execution thread and the far away subs it will contain. > 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. That's name restriction, not the container. This doesn't help when dealing with threads. Basically, global /containers/ is the root of all evil, not so much global names. > package ... ; > sub a { our $x is shared ; ... } ; > sub b { our $x is shared ; ... } ; This isn't thread-safe. There are other significant issues too, but I'll move on. > [accidentally aliasing vars to the same global] > I dont know how to stop this source of errors. Having lots of little local namespaces that get chained across long distances does away with this problem. -- ralph