Q: class name hashes
Leopold Toetsch
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 names.
We should be able to subclass PMCs as real objects.
b3.py seems to do something like:
# class TT(T):
getclass $P0, "Integer" # Integer PMC class, Python: "int" class
subclass $P1, $P0, "TT" # subclass the PMC
Then it redefines the "__repr__" method, which we BTW don't have. Using
"get_string" instead could be a problem. Seems that we need a C<repr>
vtable, which gets called when printing PMCs.
Comments welcome,
leo
Dan Sugalski
> 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 names.
Yeah. We probably ought to go rename the PMC classes to have Parrot
prefixes.
> We should be able to subclass PMCs as real objects.
Yep. We need to reserve a bit in the pmc flag word for delegated pmcs too,
but that's a semi-separate issue.
> b3.py seems to do something like:
> # class TT(T):
> getclass $P0, "Integer" # Integer PMC class, Python: "int" class
> subclass $P1, $P0, "TT" # subclass the PMC
>
> Then it redefines the "__repr__" method, which we BTW don't have. Using
> "get_string" instead could be a problem. Seems that we need a C<repr>
> vtable, which gets called when printing PMCs.
We don't need a __repr__ method. That's just an alternate freeze format.
(Arguably we need a parameter to freeze to note which format to use)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> 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 rename the PMC classes to have Parrot
> prefixes.
Ack. But ParrotResizableIntegerArray :(
> We don't need a __repr__ method. That's just an alternate freeze format.
> (Arguably we need a parameter to freeze to note which format to use)
I beg to differ. __repr__ is too universally used in Python. It's a
distinct method. A different freeze format is of course doable, but
overriding the C<repr> vtable method make this implementation a PITA.
> Dan
leo
Dan Sugalski
> Dan Sugalski <d...@sidhe.org> 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 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 character
in the name instead. Something like |Integer or :Integer. That's nasty
too, though, in its own way.
> > We don't need a __repr__ method. That's just an alternate freeze format.
> > (Arguably we need a parameter to freeze to note which format to use)
>
> I beg to differ. __repr__ is too universally used in Python. It's a
> distinct method. A different freeze format is of course doable, but
> overriding the C<repr> vtable method make this implementation a PITA.
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.
Dennis Rieks
Dennis Rieks
attached, sorry!
Dennis
--
Dennis Rieks
par...@deribo.de
Leopold Toetsch
> 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?
>>> x=0.3
>>> str(x)
'0.3'
>>> repr(x)
'0.29999999999999999'
>>> s="a\n"
>>> str(s)
'a\n'
>>> repr(s)
"'a\\n'"
> Dan
leo