We currently have two integer PMCs, we need another one for Python. But before just copy&paste another file, I'd really have done that right.
I think what we need's a policy here. Larry's weighed in on what Perl's going to want, which is cool. (In part because I'd lost track of this message :)
So, for us:
1) The base types don't change. Ints stay Ints, Strings stay Strings, and so on.
2) All language-specific PMC classes get names prefixed with their language. (So PerlInt, PerlString, and so on) If the version number gets wedged in there that's fine--language designer/porter/whoever's call. We'll also recommend a leading double-underscore, but it's not our problem if someone doesn't and there's a collision.
3) The base name for all our PMC classes has a double-underscore prepended. That means __Undef, __SArray, and so on. No, we don't have to prepend Parrot. We're special that way.
4) We should set a rule *now* that says that all parrot base types can be referenced by constant number. This should save us a lot of hassle later--if code wants a base Undef it can use the Undef number and not have to worry about whether a language has an Undef base class, or doesn't follow the naming scheme, or something.
5) We need to set up an alias and namespace system so languages can generally ignore this. Perl's going to want its base int class named "int" or "Int", and so is Python, and we should make at least a minimal attempt to set things up so that code that looks up PMC classes by name actually behaves right.
If someone wants to take on ownership of the existing PDD on our base types that's fine with me.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
