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!
