(NOTE: I invite PIR users to read this msg, and especially item #5, and let
me know whether you'll suffer any breakage when/if Parrot default namespaces
go untyped, i.e. when you're no longer allowed to have a namespace and a
global variable with the same name but distinct. HLL-specific namespaces
will be able to make their own choices, so this issue only affects those
using the default namespace objects, i.e. Patrick, Allison, & co.)
On Fri, Mar 10, 2006 at 06:45:11PM +0100, Leopold Toetsch wrote:
> On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
> >Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
> >default should be entirely untyped.
>
> The 'totally untyped' is in contradiction to the current implementation
> (which the default NameSpace PMC ought to implement) and at least to
> code in tests. I don't know, if it's used elsewhere too.
>
> And pdd21 is distinguishing these opcodes as part of the raw interface:
> $P0 = getnamespace xx
> from
> $P1 = find_global yy
>
> *if* the default namespace is really that untyped, the former isn't
> needed at all.
Interesting conflict. Resolution(s):
1. Independent of other issues, you've prompted me to notice that I omitted
namespaces themselves from the namespace typed interface. Hence the
typed interface should include {add,del,find}_namespace methods. (I'd
have committed this already but I have an svn problem this morning.)
Confidence: HIGH
2. All Parrot internal code that manipulates nested namespaces, including
(but not limited to) the getnamespace opcode, should use the typed
interface. Specifically, it should use the {add,del,find}_namespace
methods mentioned in (1).
Confidence: HIGH
3. Given (1) and (2), the getnamespace opcode is useful regardless of
whether the *default* namespace is untyped, because the it will be used
to navigate through *non*-default namespaces as well as default ones,
and non-default namespaces can be typed.
Confidence: MEDIUM
(I don't like the idea of getnamespace being slowed down by using
named PMC methods rather than hash vtable entries, but I think I
can live with it until benchmarks demonstrate it's a bottleneck.)
4. I still like the idea of Parrot's default namespace being 100% untyped,
which imposes minimum surprise on users coming from various language
backgrounds, some of which are 100% untyped. In my experience, Perl
users understand Python naming easily, but the other way is harder.
Confidence: MEDIUM
(cont.)
> Therefore I'm not really happy with removing already implemented and
> working code, the more that it would not conform to existing behavior
> anymore.
5. It's possible that making the default namespace 100% untyped won't
actually break anything; it depends on whether anyone has actually
started to depend on namespaces and globals being distinct.
Confidence: UNKNOWN
PIR users: If namespace "foo" and global variable "foo" were no longer
distinct, so you had to rename one or the other in your code, would
you suffer any breakage in the first place, and if you did, would you
have a hard time fixing it?
PS: I'd have committed {add,del,find}_namespace to pdd03 but my svn is
busted this morning.
--
Chip Salzenberg <[EMAIL PROTECTED]>
