HaloO Larry, you wrote: > On Mon, Aug 22, 2005 at 10:51:53PM +0200, Ingo Blechschmidt wrote: > : If we go with these changes, this functionality (starting place for a > : search) would be available by using > : > : Foo::Bar<$symbol_to_lookup>; # right? > > Presumably, though Foo::Bar differs from OUTER in that, for packages, > the only fallback place to look is *. We don't automatically scan > Foo after Foo::Bar, for instance. Just for the records: this implies an asymmetry between bareword outwards scans and infixed :: scans. The latter imply a prefixed *:: while the former don't, right? Or do you mean there's a single attempt to get Bar from the innermost Foo and only if *that* fails to fall back to *::Foo::Bar instead of scanning on outwards for candidates for Foo to query for Bar and eventually reaching the root and ultimately fail there. Or not even a single attempt? This would then behave like the UNIX shells I've encountered so far. That is if you have $HOME/bin in your $PATH and two subdirs $HOME/bin/foo and $HOME/bin/bar which are not in $PATH but each contain different version of some prog then neither foo/prog nor bar/prog works. <weird> Or we interpret 1) Foo::Bar and ::Foo::Bar as the single, innermost, outer access attempt 2) *::Foo::Bar as the lazy outwards scan towards root 3) **::Foo::Bar as eager outwards access that is forced to start from the root of the namespace In case 1) the ::Foo::Bar form is only needed to defer the definedness contraint while compiling or to disambiguate. Well, I guess infix wildcards *::Foo::*::Bar are then even to weird for this weirdness of mine :) </weird> > Maybe there could be some way > for Foo::Bar to delegate to Foo if it likes, though. Sort of an > inside-out import. But we've got along fine without that in Perl 5, > so I'm not going to mandate it in the base language unless we see > some really good uses for it. One that comes to mind is in providing a sandboxed environment without resorting to replicating the Perl6 root namespace environment. When you know that a boxed module needs a Foo with a certain structure you just provide that---easy enough. But if then the code you are wrapping happend to access the Bar from Foo with the oververbose syntax Foo::Bar this lookup suddenly warps out of the sandbox into the actual root environment of the interpreter... > In general we should encourage outer > classes to share with inner classes via lexical scoping rather than > package scoping, I expect. Isn't that mixing access control in an unfortunate way with the namespace manouvering syntax? OTOH, I hear me saying that privacy comes from hiding... -- $TSa.greeting := "HaloO"; # mind the echo!Thread Previous