Ticket #301 (closed RFC: wontfix)

Opened 6 years ago

Last modified 6 years ago

kill morph VTABLE

Reported by: whiteknight Owned by:
Priority: minor Milestone:
Component: core Version:
Severity: low Keywords:
Cc: Language:
Patch status: Platform:

Description

I'm doing some work converting the morph VTABLE interface to take class PMCs instead of INTVAL type ids. I'm finding a few issues:

1) Only 5 PMCs implement morph, and most of the custom implementations of it are identical functionally to that found in the default PMC. They all basically call pmc_reuse() with no other actions or side effects. 2) A lot of the PMC classes we try to morph to don't have class PMCs available, so I've been replacing a lot of VTABLE_morph calls with pmc_reuse calls in the branch.

I'm suggesting here that we remove "morph" as a vtable. Almost all of the calls can be replaced with pmc_reuse() calls directly. If we want to keep the morph opcode, we can turn it into a thin wrapper over the pmc_reuse function. Of course, that's only if anybody is really using morph, which I am starting to doubt.

Any thoughts on this?

Change History

Changed 6 years ago by coke

FYI, partcl is currently overriding morph to allow morphing between tcl PMCs.

Changed 6 years ago by whiteknight

  • status changed from new to closed
  • resolution set to wontfix

Okay, that's all the answer I really need. As part of my work in the vtable_morph_change branch, I am removing a number of VTABLE_morph calls from built-in PMCs because they're useless, redundant, and are becoming needlessly complicated. However, there is a clear case for an overridable morph interface to custom PMCs, so I won't try to remove morph completely.

Note: See TracTickets for help on using tickets.