>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:13 AM -0800 1/13/04, Jeff Clites wrote: >> Here are some notes on namespaces, picking up a thread from about a month ago: >> >>> That does, though, argue that we need to revisit the global access >>> opcodes. If we're going hierarchic, and we want to separate out the >>> name from the namespace, that would seem to argue that we'd want it >>> to look like: >>> >>> find_global P1, ['global', 'namespace', 'hierarchy'], "thingname" >>> >>> That is, split the namespace path from the name of the thing, and >>> make the namespace path a multidimensional key. >> >> I definitely agree that we should have separate slots for namespace >> and name, as you have above. So I think the discussion boils down to >> whether a namespace specifier is logically a string or an array of >> strings. >> >> Short version: I was originally going to argue for fully >> hierarchical namespaces, identified as above, but after turning this >> over in my head for a while, I came to the conclusion that >> namespaces are not conceptually hierarchical (especially as used in >> languages such as Perl5 and Java, at least), so I'm going to argue >> for a single string (rather than an array) as a namespace identifier. DS> Here's my big, and in fact *only*, reason to go hierarchical: DS> We don't need to mess around with separator character substitution. DS> Other than that I don't much care and, as you've pointed out, most of DS> the languages don't really do a hierarchical structure as such. Going DS> hierarchical, though, means we don't have to do "::"/":"/"/"/whatever DS> substitutions to present a unified view of the global namespaces. i was musing on this too and back the fully hierarchal namespace design. we won't have to worry about name separators except at conversion time. and in p5 at least, the symtable is a real HoH tree and you can pass around a section of it by reference or copy. that would be so nasty with a joined string key thingy. i did plenty of that pseudo multidim hash crap in my perl4 days. :) we have the technology to build real hash tress so let's use it as it is the natural way a symtree lives. going with a single key of a joined string doesn't seem to have any benefits. i can't even see it being so much faster. also we can always cache lookups in a single string hash for speedups. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
