On Wed, Jun 26, 2002 at 08:04:05AM -0700, Sean O'Rourke wrote:
> I'd suggest having types be integers handed out at run-time.
I thought about this before I suggested what I did, hence they TYPE
macro :) Remember, an enum is really just an integer, and your question
is about how you manage that. Additionally, the char* is also just
an integer too, and you can bet that it will be unique for any process
unless you're really nasty. But that integer's uniqueness doesn't really
address the problem the type info is for... see below...
> That way you can create new types on the fly, load libraries, etc,
> without worrying about conflicts, and without getting into nasty
> string shenanigans.
>From the POV of the programmer, who is using the API, all she
wants is "I call this type of PMC foo, and when I say give me a
new foo, give me a new PMC of that type". Telling a programmer,
"OK I see your 'foo', here is 0xdeadbeef, when you want a new 'foo'
tell me you want more 0xdeadbeef", sort of makes the API needlessly
clunky, and more difficult than it needs to be.
If a programmer says "I want this type of PMC to be 'foo' and I want
this other other type of PMC to be 'foo', and when I say I want a
new 'foo', give me the correct type", they should be laughed at
and told off with a stern error statement. We can not read software
that reads the programmer's mind, or makes up his mind for him.
So using some form or indirection doesn't protect against conflicts,
(a fool can still create a conflict), and just makes using the API
that much harder. Hence:
> int parrot_new_type(PMC * type)
Really isn't a good idea for the external API. Internally, that's a
horse of a different color...
> Given Larry's suggestions about module aliasing, these should probably be
> able to bind names relative to the current namespace, without necessarily
> knowing its name. So we might want to have an extra namespace argument
> for all these functions, and a couple of functions to manipulate
> namespaces.
God no! That way lies the path to Perl5 :) Seriously though, what I'm
recommending here is to keep it as simple as possible. Each language has
its own way of handling namespaces.
C++ & Perl5 really like '::'
Foo::Bar::Baz
Java likes to use '.'
java.System.println()
So what I'm recommending is just we let the XS writer pass this
representation in directly, through the API, to the Parser/Compiler
layer, which is what really worries about the namespace issues.
This way, Larry's ideas can be supported, but the support is done
above the Parrot level. This does mean that the Parser/Compiler layer
needs hooks to get data back from Parrot during runtime, but I'd
wager we were all assuming that was going to be the case anyways.
Parrot the VM, need not fret and furrow its pretty brow over such high
level concepts. Perl & Python will probably both use Hashes of Hashes
(or Dictionaires of Dictionaries), but a language like Forth doesn't
typically work that way (single global linear dictionary). Natrually,
Parrot the VM should probably remain as namespace agnostic as possible.
Hope this clears up something or other...
--
David J. Goehrig [EMAIL PROTECTED]
All reports, excluding those of historical fact, may be considered speculative.
- a faceless Compaq disclaimer
