Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [...]
It is, actually:
=head2 Namespace Opcodes
Note that all namespace opcodes operate from the local HLL root namespace.
Navigating outside one's own HLL namespace requires either the C<interpinfo
.INTERPINFO_NAMESPACE_ROOT> opcode or the get_namespace() compiler PMC
method.
"All namespace opcodes".
Dunno how I missed that. But that is very good news.
> Is there any reason that [...; ''] and [...] couldn't refer to the
> same namespace?
The design as it stands avoids any special meaning for *any* string. Any
string whatsoever is a valid key; any valid key is a valid namespace name.
This is a design goal that would be compromised by the '' special case.
> Tcl uses C< .namespace [''] > to refer to the root namespace (correctly, I
> think) and I can't think of any language that would want to differentiate
> between the two.
All you need to disprove this speculation is one counterexample, and the
counterexample doesn't even have to exist yet.
Fair enough. But one question remains: how do you tell IMCC that you
want to be in the root HLL namespace? C< .namespace [] > is a parse
error.
> Also, is there any reason we can't/shouldn't add find_global variants
> that lookup globals in HLL's? Right now we have find_global_p_p_s.
> Adding find_global_p_s_p_s would let me reach into Tcl's private very
> easily instead of having to crawl the namespaces myself.
It's three steps rather than one, but it's not crawling, and it's already in
the pdd, mostly:
.local pmc tcl
tcl = compreg "tcl"
.local pmc ns
ns = tcl.'get_namespace'(['Foo';'Bar'])
I'm cheating a little here because I'm showing you an example with a key
(which the docs don't specifically allow) rather than an array (which they
do allow), but the point is to demonstrate compiler.get_namespace().
This doesn't work for *private* namespaces -- only public ones. ParTcl
currently uses a macro to crawl its private namespaces, which AFAIK is
the *only* way to access the helper subs it has in private namespaces.
Thanks,
--
matt diephouse
http://matt.diephouse.com
