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
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
