<korvo>
Huh, variance in return types can be smuggled via wrapper functions that are annotated with @specialize.argtype() for each visitor. Maybe first-order tagless-final encoding is possible.
jcea has quit [Ping timeout: 248 seconds]
Dagger has joined #pypy
<arigato>
there are various hacks possible. RPython is not a syntactically well-defined OO language, instead you can build whatever classes make sense at import time, and feed that to RPython. E.g. if you want to use inheritance only for convenience in ways that wouldn't be correctly typed for RPython, you can copy all methods into the class instead of using inheritance
<arigato>
(there is a decorator somewhere that does it for you, but you can do it manually too)
<arigato>
all the @specialize decorators do something similar, they only vary in how many identical copies they end up making
<arigato>
and in whend the copy actually occurs---it can be in advance, or it can be done lazily during the RPython annotation phase
Dejan has joined #pypy
jcea has joined #pypy
<korvo>
Right. objectmodel.import_from_mixin has been useful to me in the past, for example.
<korvo>
I don't want inheritance for mixins or functionality, but for APIs; RPython won't let me duck-call objects that don't have a superclass in common, nor methods not on the superclass. I'm not sure exactly how the vtables look, but I've assumed it's like C++ vtables.
<korvo>
Of course, I suppose that after specialization, the superclass doesn't matter and the vtables will get flattened. So perhaps this is overkill or a wrong direction.