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