develooper Front page | perl.perl6.language | Postings from September 2005

Re: Symbolic dereferentiation of magical variables

Thread Previous
From:
TSa
Date:
September 21, 2005 04:15
Subject:
Re: Symbolic dereferentiation of magical variables
Message ID:
433140D4.3050604@orthogon.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About