Ticket #774 (new RFC)

Opened 5 years ago

Last modified 3 years ago

deprecate PMC multiple inheritance

Reported by: cotto Owned by: cotto
Priority: normal Milestone:
Component: pmc2c Version: 1.2.0
Severity: medium Keywords:
Cc: allison Language:
Patch status: Platform:

Description

I'd like to deprecate the behavior of pmc2c which allows C-level PMC multiple inheritance. The behavior needs supporting code which isn't properly tested in Parrot's test suite. Any modification to pmc2c that deals with a PMC's parents also needs to take this behavior into account or risk causing failures in HLLs which may not be reported for some time.

Currently the only language I know of that uses MI is Lua (partcl no longer needs it), and coke claims that MI doesn't allow anything that can't be done in another way. I've asked fperrad about how much work it would be for him to avoid MI. If it's a big deal for him (or any other HLL devs) I don't mind continuing to support it.

Once I hear back from fperrad and don't get any other objections, I'll add a proper deprecation notice so this feature can be removed post-1.4.

Change History

follow-up: ↓ 2   Changed 5 years ago by fperrad

  • cc allison added

With Lua, it's doable. It's just a code duplication.

But, I think the reason of this deprecation is not enought. For me, a good reason is something like :

multiple inheritance is a performance bottleneck.

in reply to: ↑ 1   Changed 5 years ago by bacek

Replying to fperrad:

With Lua, it's doable. It's just a code duplication. But, I think the reason of this deprecation is not enought. For me, a good reason is something like : multiple inheritance is a performance bottleneck.

I've got another reason - "multiple inheritance will require to support full C++ style virtual/diamond inheritance".

Consider this: {{[

pmclass Base {

ATTR foo

};

pmclass D1 extends Base {};

pmclass D2 extends Base {};

pmclass MyShinyClasss extends D1 extends D2 {

VTABLE bar { GETATTR(foo); }

};

}}}

(Code is sketched).

I know how to deal with this. Full implementation of "virtual" inheritance will work. But I don't want to implement good half of C++ compiler in pmc2c. And I don't want any parrot's developer to learn how to do this.

-- Bacek

follow-up: ↓ 4   Changed 5 years ago by fperrad

We don't need a C++ like multi-inheritance.

Multi-inheritance of abstract PMC without ATTR is enought. It's more a Java like multi-inheritance.

in reply to: ↑ 3   Changed 5 years ago by bacek

Replying to fperrad:

We don't need a C++ like multi-inheritance. Multi-inheritance of abstract PMC without ATTR is enought. It's more a Java like multi-inheritance.

Java like multi-inheritance doesn't inherit implementation at all... And all our pmcs have exactly same set of VTables.

-- Bacek

  Changed 3 years ago by coke

  • owner set to cotto
  • type changed from cage to RFC

Changing to an RFC - this is asking for a design decision.

  Changed 3 years ago by cotto

I'd like to remove this because, as far as I can tell, it's an unintended quirk of the pmc2c code rather than an intentional feature. That said, it's not costing us anything to keep it around. If someone does want to remove it, please patch Lua first. After that, we can remove this feature. Until then, consider it deprecated pending proper notice.

Note: See TracTickets for help on using tickets.