(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]>