Comments on namespace patch part 23 (wow, 23)
Chip Salzenberg
On Wed, Mar 15, 2006 at 08:14:20AM -0800, l...@cvs.perl.org wrote:
> - initial/default HLL namespace is "parrot"
I didn't ask for a default, and I don't think there should be one, but I'm
interested in your reason for adding one.
Rationale: the system as a whole *is* Parrot. Looking at Parrot in
context of a running computer system, there is a notional (not actual)
"parrot::" before *Everything* in a running parrot system. Adding an
explicit "parrot::" seems to me like adding an explicit "perl::" to the
beginning of every Perl package name.
> - store_global, find_global w/o namespace are now relative to
> current namespace
Excellent.
> - intermediate workaround for 'newclass / .namespace': try current and HLL
> namespace to find class namespace
Good workaround, thanks.
> - getnamespace is absolute to namespace root
I don't think that's a good idea. Once we start making exceptions to the
relativity rule, users will have to memorize those exceptions, and then some
opcodes will become less useful. By my intention, the only way to get to
the namespace root should be via introspection (interpinfo).
On the other hand, I think we should consider get_namespace and find_global
opcodes that accept a namespace PMC as the "root" for the search. Linux
just added a whole raft of analogous system calls. For example, in recent
Linux you can open /etc/motd in two ways, either:
int fd = open("/etc/motd", O_RDONLY);
or:
int etc_fd = open("/etc", O_RDONLY | O_DIRECTORY)
int fd = openat(etc_fd, "motd", O_RDONLY);
I think Parrot opcodes like "get_namespace_at" or "find_global_at" (not
necessarily with those names), modeled on the Linux openat() family, will
address the usability problem that you seem to be addressing with your
getnamespace root exception, while also being useful in other circumstances.
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
On Mar 15, 2006, at 20:21, Chip Salzenberg wrote:
> Neat work, Leo! Couple of comments & requests:
Thanks, yet unfinished though ...
> On Wed, Mar 15, 2006 at 08:14:20AM -0800, l...@cvs.perl.org wrote:
>> - initial/default HLL namespace is "parrot"
>
> I didn't ask for a default, and I don't think there should be one, but
> I'm
> interested in your reason for adding one.
>
> Rationale: the system as a whole *is* Parrot. Looking at Parrot in
> context of a running computer system, there is a notional (not
> actual)
> "parrot::" before *Everything* in a running parrot system. Adding
> an
> explicit "parrot::" seems to me like adding an explicit "perl::" to
> the
> beginning of every Perl package name.
The rational for a default "parrot" namespace is simple. Parrot PMC are
bootstrapping themselves by first registering PMC vtables and PMC types
and then methods and MMDs[1]. The methods and MMDs need some kind of
namespace. We were discussing this on IRC a bit. Before all the PMCs
were occupying toplevel namespace names. Now it's "::parrot::Integer"
and so on.
We have already a default HLL named 'parrot' - the initial one in the
absence of any .HLL directive. Therefore it was just straightforward to
use the default ``HLL namespace'' "parrot" as the default one.
I'm of course fine with any other name.
>
>> - store_global, find_global w/o namespace are now relative to
>> current namespace
>
> Excellent.
>
>> - intermediate workaround for 'newclass / .namespace': try current
>> and HLL
>> namespace to find class namespace
>
> Good workaround, thanks.
Need more specs though. The plan as also described in the roundup mail
is:
.namespace "Foo"
.sub some
cl = newclass "Foo" # namespace "Foo::Foo"
...
or in other words, it's breaking a lot of code. The correct sequence
would need:
# implicit .namespace [""] at top of file, actually all below HLL
namespace
.sub some
cl = newclass "Foo" # namespace "Foo"
.end
.namespace "Foo"
.sub some_other
cl = newclass "Bar" # namespace "Foo::Bar"
.end
Alternatively, we'd need some other means to create nested classes
along with their namespaces.
>
>> - getnamespace is absolute to namespace root
>
> I don't think that's a good idea. Once we start making exceptions to
> the
> relativity rule, users will have to memorize those exceptions, and
> then some
> opcodes will become less useful. By my intention, the only way to get
> to
> the namespace root should be via introspection (interpinfo).
Well, I've asked that already and see pdd21:
$P1 = get_namespace ["perl6"; "Foo"]
> On the other hand, I think we should consider get_namespace and
> find_global
> opcodes that accept a namespace PMC as the "root" for the search.
[ ... ]
Whatever might be best. It's not hard to change it now, but we should
have a decision towards final.
BTW could you please add a note to pdd21, how the "add_namespace"
opcode is supposed to work exactly (which namespace name does it create
where)
[1] see the generated file: src/core_pmcs.c:175 and following
leo