Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Ramblings on creating a new VTABLE_call_method "slot" to help with implementing Python's bound vs unbound methods:
http://www.intertwingly.net/blog/2005/01/03/Bound-Methods
1) Methods are functions, where the first parameter is the object.
We are currently passing the object (or the invocant) in current_object In subs denoted with "method" we have the magic "self", which makes it available for user code.
This doesn't match HLLs expectations and sematics.
Proposal:
P5 := object := invocant for method calls ex-P2 := current_invocant (now current_object aka self)
So given:
def index(self, substr)
We have the common case of a method call and matching arguments:
"parrot".index("r")
P5 ... "parrot" P6 ... "r" current_invocant ... "parrot"
With an unbound method call:
str.index("parrot", "r")
with this register setup prior to the call:
P5 ... str P6 ... "parrot" P7 ... "r" current_invocant ... str
we have to do:
if (PObj_is_class_TEST(object)) shift_arguments(...);
and we have again arguments matching.
How should the following be handled:
f = "parrot".index
...
print f("r")2) WRT the proposed VTABLE_call_method()
This just moves the burden of doing a method call down to all classes and doesn't really fix anything. 1) is not python-specific. Moving the code into language-specific PMCs hinders interoperbility and causes unneeded code duplication.
I've learned to expect such a predictable response. The exact same number of lines of code, and the exact same external behavior somehow magically hinders interoperability and causes unneeded code duplication.
Whatever.
- Sam Ruby
