[pypy-svn] r20210 - pypy/branch/somepbc-refactoring/pypy/doc/discussion

[mwh at codespeak.net]

Author: mwh
Date: Thu Nov 24 14:47:26 2005
New Revision: 20210

Modified:
   pypy/branch/somepbc-refactoring/pypy/doc/discussion/somepbc-refactoring-plan.txt
Log:
some thoughts.


Modified: pypy/branch/somepbc-refactoring/pypy/doc/discussion/somepbc-refactoring-plan.txt
==============================================================================
--- pypy/branch/somepbc-refactoring/pypy/doc/discussion/somepbc-refactoring-plan.txt	(original)
+++ pypy/branch/somepbc-refactoring/pypy/doc/discussion/somepbc-refactoring-plan.txt	Thu Nov 24 14:47:26 2005
@@ -152,3 +152,26 @@
 consider_call_site() should not add new (unmerged) rows to the table
 after the table is considered "finished" (again, unless there is only
 one column, in which case we should not discover new columns).
+
+XXX this is now out of date, in the details at least.
+
+RTyping other callable PBCs
+===========================
+
+The above picture attaches "calltable" information to the call
+families containing the function.  When it comes to rtyping a call of
+another kind of pbc (class, instance-method, frozenpbc-method) we have
+two basic choices:
+
+ - associate the calltable information with the funcdesc that
+   ultimately ends up getting called, or
+
+ - attach the calltable to the callfamily that contains the desc
+   that's actually being called.
+
+Neither is totally straightforward: the former is closer to what
+happens on the trunk but there is no obvious place to attach the
+information, unless maybe normalization can essentially remove all
+callables from FuncDescs from the graph?  The latter is more of a
+change.  The former is also perhaps a bit unnatural for ootyped
+backends.