Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> # find_method class 'A' method '__absolute': Sub
>> # Calling sub '__absolute'
> But only for classes that inherit from delegate.
Yes of course. Objects's derived from ParrotObject (i.e. Parrot standard
objects) dispatch to overloaded functions via the meta-class helper
class "delegate". Standard PMCs call pmc->vtable->absolute().
But infix operations like the "add" opcode dispatch via mmd_dispatch_*
and have no delegate functionality.
I've posted a graphic of all these possibilities in one of the mails.
This is the reason why I'm prefering to replace all with just one
scheme that works, i.e. doing full dynamic dispatch at the opcode level.
> People writing Python to Parrot translators need to know Parrot
> internals. People who merely write in Python should not.
Why on earth should Python writers know Parrot internals? Why do you
come to such a conclusion?
>>>... (BTW, a combined instantiate method
>>>does not map well to Python which has separate __new__ and __init__
>>>methods.
>>
>> We have the "__init" hook too. This is separate.
> Ultimately, I believe that this will need to be revisited.
What is wrong? Does it not work?
>>>... My recommendation
>>>is to stick to primitives, and simply provide a new_p_p).
>>
>> What is the second "_p" for?
> What I am thinking of is something like:
> inline op new(out PMC) {
> $1 = VTABLE_instantiate(interpreter, $2);
There is no second argument on the "new" signature. But I presume it's a
class PMC. Well doing:
cl = getclass "Foo"
o = cl."instantiate"()
does exactly that - it constructs a new Integer with the default value by
calling pmc_new/init.
OTOH when you have
cl = getclass "Foo"
o = cl."instantiate"(5)
you have two possiblities: implement the "instantiate" vtable (or let a
user provided overridden method do the initialization) or do the init
stuff in "__init", which get's again the arguments according to pdd03.
> .... If you then want to init the PMC you have
> obtained, you can use the separate init hook (with a variable number of
> arguments).
This is working already.
.sub main
.local pmc cl, o
cl = subclass "Integer", "A"
o = cl."instantiate"(5)
print o
print "\n"
.end
.namespace ["A"]
.sub __init method
.param int i
self = i
.end
> The code that backs perl classes can have implementations find_method
> that looks for __add methods with a given parameter signature, and the
> code that backs python classes can have implementations of find_metho
> that looks for __add__ methods with a different parameter signature.
Sam, there *should* be no difference between a pythonic "__add__"
and Parrot's "__add". Currently calling conventions don't match - I've
posted a mail WRT this and it needs fixing.
And Perl doesn't have an "__add" or such. Perl5 has "use overload '+' =>
..." Perl6 has a special infix:<+> syntax.
So the prerequisit is that Parrot's function signature of overloaded
methods is appropriate for Python and Perl.
We have:
a = b + c
You already did show the Python code, which emits the Parrot opcode
"add", which does MMD dispatch. But we both posted an example that
overloads the operator "+" with a piece of user provided function.
You've stated that the code to provide this functionality is missing in
py*.pmc. But when you write it, you have of course to know, that a
setattribute (or a __dict__ update) with the key "__add__" is meaning an
overload of the "+" operator. Else you wouldn't be able to roll your own
dispatcher.
So when your translator encounters:
def myadd(self, r):
return self - r
class J(int):
__add__ = myadd
i = J(44)
print i, i + 2
you have to know that "myadd" will be the function that is called, when an
"add" operation for an object of class "J" is executed. This is the
place where you would call:
Parrot_store_global(interp, "J", "__add", myadd);
The subroutine PMC myadd is stored into the namespace of "J" as
the subroutine labeled "__add".
In the current system you would have to call "mmdvtregister" to
associate the "myadd" subroutine with the "add" opcode for the given
types - but that doesn't work for objects derived from class "J" nor for
mixed types.
So what I'm saying (or I'm trying to) is: when at the opcode level the
"add" opcode is actually acting as a method call, everything works as
now including dynamic overriding of MMD functions. And there is no need
at all for duplicating a lot of Parrot core functionality in the
py*.pmcs.
I've described that in "MMD dispatch". With the help of the inline cache
this scheme is 30% faster then the current static MMD table dispatch.
> - Sam Ruby
leo
