[pypy-dev] A problem with unbound methods
anto.cuni at gmail.com
Wed Apr 12 17:03:44 CEST 2006
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
More information about the Pypy-dev