Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I just went digging through the docs to make sure I knew what was going
> on. __repr__ is the python-visible name for our get_string vtable method.
> We don't need any support beyond tying names together in the namespaces,
> so far as I can see.
Sure?
>>
Don't know what happens to my Mailclient, but there are some Spam Messages
attached, sorry!
Dennis
--
Dennis Rieks
[EMAIL PROTECTED]
On Wednesday 23 June 2004 16:19, Dan Sugalski wrote:
> > > Yeah. We probably ought to go rename the PMC classes to have Parrot
> > > prefixes.
> >
> > Ack. But ParrotResizableIntegerArray :(
>
> Yeah, I know. It's nasty. :(
>
> I suppose for internal things we could use a "non-legal" prefix charact
On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> >> I think both should use just interpreter->class_hash. OTOH putting PMC
> >> names into this one hash makes it more likely that we get name
> >> collisions for
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jun 2004, Leopold Toetsch wrote:
>> I think both should use just interpreter->class_hash. OTOH putting PMC
>> names into this one hash makes it more likely that we get name
>> collisions for user class names.
> Yeah. We probably ought to go rena
On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> We currently seem to have two different hashes for storing class names:
> one for PMC base classes and one for dynamic PMCs and objects.
>
> I think both should use just interpreter->class_hash. OTOH putting PMC
> names into this one hash makes it more
We currently seem to have two different hashes for storing class names:
one for PMC base classes and one for dynamic PMCs and objects.
I think both should use just interpreter->class_hash. OTOH putting PMC
names into this one hash makes it more likely that we get name
collisions for user class
