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. 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. > - Sam Ruby leo
