[pypy-dev] A problem with unbound methods

Antonio Cuni anto.cuni at gmail.com
Wed Apr 12 17:03:44 CEST 2006

Hi Armin,

Armin Rigo wrote:
> We could try to do this in a way that is reusable between multiple
> back-ends, because many OO back-ends will have a similar problem.  What
> needs to be done is to collect all graphs and see how they are used.
> For each graph, it means: which regular method(s) are implemented with
> that graph, and which direct_calls are done to staticmethods implemented
> with that graph.
> Then we need some cases.  We can be more sutble, but as a minimum we
> need logic like: if a graph is used only as one method, leave it alone.
> If it is used only as a static method, leave it alone too (and declare
> it as a static method somewhere).  For more complicated cases, find all
> methods implemented with this graph, and replace each of them with a new
> stub graph that just contains a direct_call to the original graph as a
> static method.
> Such a transformation would "normalize" the methods in the OOClass
> objects (so that the approach you're currently using in CLI would
> continue to work for methods) and also generate a list of remaining
> graphs that the back-end needs to declare as static methods.

It sounds reasonable. At the moment by backend suffers just this 
problem: is a graph is used both as bound and unbound method it will be 
rendered twice. I though to resolve it in some CLI specific way, but a 
more general approach is better.

By now the few logic I do is localized in translator/cli/database.py, 
but it is too CLI specific to be reusable: maybe I could try to factor 
out the backend-independent logic for later reuse. Another good thing to 
factor out could be the "pending nodes" logic: at the moment both gencli 
and gensqueak implements that logic independently, but it would be nice 
to have a reusable framework shared by gensqueak, gencli and possibly 
other backends.

ciao Anto

More information about the Pypy-dev mailing list