Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: cvs commit: parrot/t/pmc object-meths.t

5 views
Skip to first unread message

Sam Ruby

unread,
Feb 1, 2005, 8:27:33 AM2/1/05
to l...@cvs.develooper.com, Perl 6 Internals
l...@cvs.develooper.com wrote:

> + 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

[1] http://xrl.us/exsu

Leopold Toetsch

unread,
Feb 1, 2005, 9:20:29 AM2/1/05
to Sam Ruby, perl6-i...@perl.org

>> + 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

Sam Ruby

unread,
Feb 1, 2005, 9:43:58 AM2/1/05
to l...@toetsch.at, perl6-i...@perl.org

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

Leopold Toetsch

unread,
Feb 1, 2005, 11:20:03 AM2/1/05
to Sam Ruby, perl6-i...@perl.org
Sam Ruby <ru...@intertwingly.net> wrote:

> 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

0 new messages