Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> Here's the part that you snipped that addresses that question:
> > And there is a piece that I haven't written yet that will do the
> > reverse: if MMD_ADD is called on a PyObject that has not provided
> > such behavior, then an any __add__ method provided needs to be
> > called.
Ok. But that would imply that HLL interoperbility isn't really possible. Or
just at a minimal surface level. But see below.
> Since you provided an Evil Leo sample, let me provide an Evil Sam sample:
> d = {
> "__init__": lambda self,x: setattr(self, "value", x),
> "__add__": lambda self,x: str(self.value) + str(x.value)
> }
> def dict2class(d):
> class c: pass
> c.__dict__.update(d)
^^^^^^^^^^^
This is the critical part of it. The "__dict__" of your class provides the
namespace. Setting a key in that namespace (or an attribute of your class
with that key) has a special meaning in Python, *if* that key happens to
be one of the method names.
While the Python people aren't stopping to talk about the clearness of
their language, nothing is clear and explicit, when it comes to overloading
or metaclasses.
Anyway, IMHO, "class.__add__ = foo" or your example manipulating
"class.__dict__" (another special attribute name!) is the point, where
you can install Parrot semantics WRT method overloading.
> Now, given the above sample, let's revisit the statement that "The
> Python translator needs just a translation table for the common core
> methods."
We both know that's a simplification :) You've to install the methods of
course ...
> How, exactly, would that be done? Given that the method name is simply
> a string... used as a key in dictionary... with a different parameter
> signature than the hypothetical Parrot __add method.
The "class.__dict__" dictionary is special. Setting an "__add__" key too.
The combined meaning is overloading. The different signature is a
problem, yes - I've already mentioned that. And Parrot's "__add" method
is not hypothetical :-)
$ grep __add t/pmc/object*.t
> That's why I say:
>>>In the general case, looking for "reserved" method names at "compile"
>>>time doesn't work.
>> "__add__" is reserved in Python and corresponds directly to "__add" in
>> Parrot. I don't think that doesn't work.
> __add__ is *not* reserved in Python.
Does it matter if the name is actually reserved? The meaning is
important.
> ... There just is some syntatic sugar
> that provide a shorthand for certain signatures. I am free to define
> __add__ methods that have zero or sixteen arguments. I won't be able to
> call such methods with the convenient shorthand, but other than that,
> they should work.
I'd say, if you define an '__add__' method with 16 arguments, Python
will throw an exception, if you try to use C<+> with an object of that
class:
TypeError: myadd() takes exactly 16 arguments (2 given)
So that's rather hypothetical. And if you always use x."__add__"(16
args) Parrot will just run the function.
>>>I personally don't think that performance considerations should be out
>>>of bounds in these discussions
>>
>> I've already shown that it's possible to go with fully dynamic dispatch
>> *and* 30% faster for MMD and 70% faster for overloaded operations. First
>> correct and complete, then speed considerations.
> Neither of which match Python semantics. We are going to need a system
> where classes are anonymous, not global.
Why? And how do you find your class then:
c = C()
...
3 22 LOAD_NAME 1 (C)
25 CALL_FUNCTION 0
> ... Where methods are properties
> that can be added simply by calling the equivalent of set_pmc_keyed.
Nah. Methods aren't properties, but ...
The "set_pmc_keyed" on "__dict__" (or an equivalent setattribute call)
of your type system is responsible to create Parrot semantics for method
calls :-)
> - Sam Ruby
leo
