Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
How should the following be handled:
f = "parrot".index
The CPython code is:
1 0 LOAD_CONST 0 ('parrot') 3 LOAD_ATTR 0 (index) 6 STORE_NAME 1 (f)
The interesting thing is hidden in LOAD_ATTR. It seems that it creates a call stub for the given (object, method) pair.
...
print f("r")
That looks like and is a plain function call (BTW it's not covered by your call_method proposal). The "f" object (the method call stub) has to shift up call arguments and place the object as the first argument.
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.
What is unclear about: "This just moves the burden of doing a method call down to all classes and doesn't really fix anything."?
First you state "The "f" object (the method call stub) has to shift up call arguments and place the object as the first argument."
In other words, moving the burden of doing the marshalling of parameters down to the class really *does* fix something.
Then you state that moving the burden in a similar case doesn't fix anything.
Whatever.
Again: the problem is *not* python-specific.
Analogy: is classes/string.pmc Perl Specific?
I anticipate each language will need a language specific string class. Hopefully each will inherit much of their functionallity from Parrot's string class once all the multiple inheritance and MMD issues are worked out.
In a similar manner, I expect many languages will need a language specific "class" class. Again, hopefully each will inherit much of their functionallity from a Parrot "class" class.
If you take a look at my recent commit, you will see that the way that bound methods are implemented in Python leverages the way that Python Properties are defined. This isn't merely an implementation choice - this is the way the language is defined, and t/pie/b0.t seems carefully crafted to ensure that the implementation faithfully implements this part of the Python language definition.
I suspect that much of this is Python specific. That's why it is nice that VTABLE_get_attr_str is a VTABLE entry and not hardwired into Parrot_getattribute_p_p_sc.
In a similar manner, I expect most languages to implement call_method to either simply inherit the default or to implement the same basic flow of find_method followed by invoke. What is in between those two calls, however, may vary based on language - for example, what exception is to be thrown if the method is not found may vary from language to language.
However, I can't override this behavior if it remains hardcoded in the op. Moving the burden down to the classes *does* allow me to fix something - it enables me to throw the exception that Python developers will expect, and will allow me to avoid the creation of bound method objects in many cases.
- Sam Ruby
