[perl #31987] Should predefined pmcs inherit nci methods?
Sam Ruby
# Please include the string: [perl #31987]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31987 >
Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray?
I'm assuming the answer is yes, as classes defined via the subclass
opcode seem to inherit non-vtable methods. In fact, I've made a number
of assumptions, any of which could invalidate the attached patch.
- Sam Ruby
Leopold Toetsch
> I'm assuming the answer is yes, as classes defined via the subclass
> opcode seem to inherit non-vtable methods. In fact, I've made a number
> of assumptions, any of which could invalidate the attached patch.
I've applied the non-inheritance pieces of the patch.
> - Sam Ruby
Thanks,
leo
Leopold Toetsch
> Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. But it's not quite finished. Objects derived from
PMCs inherit methods of the parent, but one level only. PMC inheritance
isn't followed yet IIRC.
> I'm assuming the answer is yes, as classes defined via the subclass
> opcode seem to inherit non-vtable methods. In fact, I've made a number
> of assumptions, any of which could invalidate the attached patch.
I'll look through it. But we'll very likely not do the static
inheritance by duplicating NCI method slots. That would prevent to
override a base class method.
> - Sam Ruby
leo
Dan Sugalski
>Leopold Toetsch wrote:
>>Sam Ruby <parrotbug...@parrotcode.org> wrote:
>>
>>>Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray?
>>
>>Yes. But the inheritance should be (and is AFAIK already partially) in
>>the method lookup. But it's not quite finished. Objects derived from
>>PMCs inherit methods of the parent, but one level only. PMC inheritance
>>isn't followed yet IIRC.
>
>__add__ method to pyobject and I can't access it from pyint...
>however I can access sort from ResizablePMCArray. Weird.
There are two basic classes of methods here. (And classes of classes,
something I'm regretting, and I think we'll redo once I get a handle
on metaclasses and just unify it all)[1]
The first is the vtable method stuff. There's a static single
inheritance scheme when Parrot's built. These methods are the *C*
methods (not NCI or bytecode) and they get filled in at parrot build
time. There's no runtime inheritance, lookups, or anything. The fixed
method is what's called. (That the fixed method may then delegate to
parrot methods confounds things a bit)
The second is the *parrot* method stuff. These generally do a search
of the hierarchy, at least if you're making a method call on a thing
that's a ParrotObject. If you're making a method call on something
else it depends on whether the method invocation code for that thing
knows how to traverse the hierarchy.
So basically it's a bit of a muddle, and it needs swamping out.
[1] And yes, I am being dragged deep into objects. Kicking and
screaming, but still..
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Sam Ruby
It still doesn't make sense to me. Try adding the following line to
both fixedpmcarray.pmc and perlint.pmc:
METHOD INTVAL inheritme() { return 42; }
Then try running the following:
.sub _main @MAIN
print "test 1\n"
$P0 = new ResizablePMCArray
$I1 = $P0."inheritme"()
print $I1
print "\n"
print "test 2\n"
$P0 = new Boolean
$I1 = $P0."inheritme"()
print $I1
print "\n"
.end
The output I get is:
test 1
42
test 2
Method 'inheritme' not found
in file '(unknown file)' near line -1
Apparently FixedPMCArray and PerlInt are different kinds of classes?
In any case, I would like to create some PMCs to represent Python
classes. And I would like to implement as many of the methods as I can
in C. And I would like such methods to be inherited.
I'm OK with a temporary solution (like the patch I provided) until a
"real" solution can be put in place.
Suggestions welcome.
> [1] And yes, I am being dragged deep into objects. Kicking and
> screaming, but still..
- Sam Ruby
Leopold Toetsch
> There are two basic classes of methods here. (And classes of classes,
> something I'm regretting, and I think we'll redo once I get a handle
> on metaclasses and just unify it all)[1]
> The first is the vtable method stuff. There's a static single
> inheritance scheme when Parrot's built.
And a bit of hackish multiple inheritance. OrderedHash isa Array and isa
Hash. It's still static and not really supported by the PMC compiler
albeit needed.
E.g. a TclString isa tclobject (which handles morphing). OTOH it really
should be a String too: almost all worker functions are the same.
A usable scheme for multiple inheritance at the PMC level could vastly
reduce code multiplication and reduce implementation errors.
> The second is the *parrot* method stuff. These generally do a search
> of the hierarchy
And we have a third category: real objects that inherit from PMCs. E.g.
some snippets from the pie-thon tests:
# b3.py
...
T = int
class TT(T):
def __repr__(self):
return "T(%d)" % self
class Int(TT):
...
TT.__cmp__ = icmp
The C<int> thingy is a "PyInteger" PMC. C<TT> and C<Int> inherit from
it, e.g. the compare MMD function, which gets overridden in the middle
of the inheritance chain.
Which leads to a nice project called MMD inheritance ...
leo
Leopold Toetsch
> It still doesn't make sense to me. Try adding the following line to
> both fixedpmcarray.pmc and perlint.pmc:
> METHOD INTVAL inheritme() { return 42; }
Ok, that's exactly that part, which currently *is* broken. If you have
some time please read src/objects.c:1237 ff. The code is unfinished and
wrong:
- it follows only one parent and stops then
- it apperently is wrong, if there is a longer chain of parents
Shouldn't be too hard.
> - Sam Ruby
leo
Leopold Toetsch
[ PMC method inheritance ]
> Patch attached.
Thanks, applied.
leo