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