Q: interpreter->stash and namespaces
Leopold Toetsch
*) I presume that the stash_hash is the thing, that holds the top-level
namespace.
*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)
*) what is Parrot_Context.current_package? Shoudn't that better be a
PMC* current_namespace (if we want to cache the current_subs's namespace)?
leo
Chip Salzenberg
> *) what is Stash.parent_stash? (It's currently unused)
Historically, "stash" is perl5-guts-speak for "namespace". However, I see
in Parrot the Stash structure which seems quite different. From its usage,
I gather it's an attempt at layered or translucent namespaces -- where one
namespace underlies another and is only consulted when the top one does not
contain the name being searched for. Interesting, but puzzling. Let it
live. For now.
> *) I presume that the stash_hash is the thing, that holds the top-level
> namespace.
Each stash_hash should now hold a pointer to a namespace. But why call it
"top-level"? It seems to me, based on its construction, that a Stash could
refer to any namespace, not just the top-level one.
> *) what is vtable->package? A pointer to the namespace PMC of this
> class? (It's currently unused)
Beats me. Vtables don't have namespaces. Pleaes just comment it as "WTF?"
(or equivalent :-)).
> *) what is Parrot_Context.current_package? Shoudn't that better be a
> PMC* current_namespace (if we want to cache the current_subs's namespace)?
Yes, it should be current_namespace. And I think the 'getpackage' and
'setpackage' opcodes are going away, to be replaced with more robust
namespace operations. (I have no idea why anybody [even Dan :-)] would have
thought that caching the current package's *name* would be particularly wise
or useful. Names change, but a PMC* is forever.)
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:
> On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
>> *) what is vtable->package? A pointer to the namespace PMC of this
>> class? (It's currently unused)
>
> Beats me. Vtables don't have namespaces. Pleaes just comment it as
> "WTF?"
> (or equivalent :-)).
Given that in P6 speak ...
00:27 < stevan> Class.isa(Package)
00:27 < stevan> Class.isa(Module), Module.isa(Package),
Package.isa(Object)
See also pugs/trunk/src/PIL/Native/Bootstrap/*.pil
... and a package/module is a namespace, it would make some sense, that
a vtable (which is part of the PMC class scheme) has a 'namespace'
field (as it already has 'class' and 'mro' fields).
Well, there is another vtable function that is very much related with
that: C<STRING* namespace_name()> currently used just for an extra
indirection to burn some CPU cycles in method lookup.
But without further separation of the objects vs class semantics of a
PMC and w/o interfaces probably not ;)
leo
Chip Salzenberg
> On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:
> >On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
> >>*) what is vtable->package? A pointer to the namespace PMC of this
> >>class? (It's currently unused)
> >
> >Beats me. Vtables don't have namespaces.
>
>
> 00:27 < stevan> Class.isa(Package)
> 00:27 < stevan> Class.isa(Module), Module.isa(Package), Package.isa(Object)
>
> See also pugs/trunk/src/PIL/Native/Bootstrap/*.pil
>
> ... and a package/module is a namespace, it would make some sense, that
> a vtable (which is part of the PMC class scheme) has a 'namespace'
> field (as it already has 'class' and 'mro' fields).
>
> Well, there is another vtable function that is very much related with
> that: C<STRING* namespace_name()> currently used just for an extra
> indirection to burn some CPU cycles in method lookup.
Ah yes, of *course*. PMCs have methods, and the methods need to be found
somewhere, so the default place to look should be vtable->namespace.
Is there a problem with killing vtable->namespace_name and replacing its
usages with the existing vtable->namespace?
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
On Jan 26, 2006, at 5:35, Chip Salzenberg wrote:
> Ah yes, of *course*. PMCs have methods, and the methods need to be
> found
> somewhere, so the default place to look should be vtable->namespace.
>
> Is there a problem with killing vtable->namespace_name and replacing
> its
> usages with the existing vtable->namespace?
No problem. But vtable->namespace could be vtable->method_hash to
better reflect it's, I think.
leo