> + else if (p->vtable->base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI class which subclasses the base NCI class.
- Sam Ruby
>> + else if (p->vtable->base_type == enum_class_NCI) {
> It was requested[1] that I not add any Python specific methods to the
> NCI method... accordingly, the majority of Python methods are morphed to
> a PyNCI class which subclasses the base NCI class.
Well, I know that the above test isn't quite right. It should be:
if (VTABLE_isa(INTERP, p, CONST_STRING(INTERP, "NCI")))
But that needs still more work - better PMC class inheritance in that
case. I've proposed to add an "mro" array to PMCs to simplify
inheritance checks.
[ for now, I've put in above line - should work ]
> - Sam Ruby
leo
But then you effectively morph the resulting bound method into a NCI
instead of a PyNCI with the following line of code:
bound_meth->vtable = Parrot_base_vtables[enum_class_Bound_NCI];
Delegation is more appropriate in this instance, and would be able to
handle both NCIs and PIR methods with equal ease.
- Sam Ruby
> But then you effectively morph the resulting bound method into a NCI
> instead of a PyNCI with the following line of code:
> bound_meth->vtable = Parrot_base_vtables[enum_class_Bound_NCI];
Yes. That's a general problem in all places, where the Parrot core
creates a PMC that might be overridden in a specific HLL.
I've proposed that we should have a table of core PMC => HLL mappings so
that depending on the current language a correct PMC class is created.
This is probably more important for scalar types, as basic math
operations are usually the same, then in object-ish code, where
differences tend to be bigger.
> Delegation is more appropriate in this instance, and would be able to
> handle both NCIs and PIR methods with equal ease.
How should default.pmc:get_attr_str() look like?
> - Sam Ruby
leo