Sam Ruby <[EMAIL PROTECTED]> wrote: > The common cases I want to optimize for are common functions being > called as common functions. And common methods being called as methods.
Yep, that's very reasonable. > The easiest way to optimize for the common methods being called as > methods is if the current object is not passed as the first argument. Why so? Python methods don't have a notion of an object - it's just the first argument passed into a function. So I don't quite understand your conclusion. This isn't a python-only problem. Perl5 doesn't have an object either. Perl6 multi-methods provide both "features": foo($a, $b); # probably a MMD call on both $a.foo($b); # a method call on 1st invocant The function or multi-sub "foo" can be basically anything in the first case including a lexical function "foo" and not a method at all. As long as we have different calling conventions for these 2 variants we have just a better chance for a mismatch IMHO. > Yes, copying will be required in cases where functions are called as > methods. How do you detect this case and when are arguments shifted then - note: I prefer the term shifting as copying is done anyway in all sub calls (see src/sub.c:copy_regs). > - Sam Ruby leo
