Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support interfaces having multiple base interfaces #2711

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

CountBleck
Copy link
Member

Changes proposed in this pull request:
⯈Adding support for an interface extending multiple interfaces.

  • I've read the contributing guidelines
  • I've added my name and email to the NOTICE file

@CountBleck CountBleck force-pushed the interface-multiple-extension branch from eb15e88 to f166f39 Compare June 21, 2023 05:42
@CountBleck CountBleck requested a review from dcodeIO June 21, 2023 06:09
@CountBleck CountBleck requested review from dcodeIO and removed request for dcodeIO June 30, 2023 03:45
@dcodeIO dcodeIO self-assigned this Jun 30, 2023
@CountBleck
Copy link
Member Author

@dcodeIO How does it look?

@CountBleck CountBleck force-pushed the interface-multiple-extension branch 4 times, most recently from 65ac5ee to ca007de Compare July 23, 2023 17:43
@CountBleck
Copy link
Member Author

Whoops, needed to rebase. It should work now.

@CountBleck CountBleck force-pushed the interface-multiple-extension branch from ca007de to 94a2c28 Compare July 24, 2023 06:18
@CountBleck CountBleck requested review from dcodeIO and removed request for dcodeIO October 2, 2023 14:29
This is a feature in TypeScript, and I didn't see much of a technical
reason to disallow it. By changing interface extension such that
implementsTypes and interfacePrototypes are used for base interfaces
instead of extendsType and basePrototype in InterfacePrototype and
Interface respectively, and by modifying the parser, existing code
doesn't seem to break, and multiple base interfaces are possible (if not
working already).

There was also a small change to the instanceof helper generation, where
arrays are now used instead of Sets, since I needed to filter for
interfaces, and Set_values was used on the constructed Set regardless.
However, the change also modified the order of instanceof checks as seen
in instanceof.debug.wat. The instanceof.release.wat file underwent more
drastic changes, but it still appears to work anyway.
Without inspecting the resulting WAT, and instead concluding based on
the test compiling successfully and executing without any errors,
everything seems to work properly.
@HerrCai0907
Copy link
Member

HerrCai0907 commented Jan 15, 2024

Could you explain more about the target behavior of extended interfaces and how to handle the conflict between different base interfaces.
Maybe you need to add more test cases for those.

@CountBleck
Copy link
Member Author

Could you explain more about the target behavior of extended interfaces and how to handle the conflict between different base interfaces.
Maybe you need to add more test cases for those.

Ah, I didn't see this. From my understanding, I don't think there should be any conflict, because the implementer needs to satisfy all of the requirements imposed by each interface, whereas the interface has no requirements imposed on it by the implementer, asides from a case being added to each of the interface's override (virtual) stubs.

I could of course be very wrong about this, but I don't know what else should be tested.

@HerrCai0907
Copy link
Member

interface A {
  f(): void;
}

interface B {
  f(): i32;
}

interface C extends A, B {}

class D implements C {
  f(): void {}
}

For this case, TS will diagnose Interface 'C' cannot simultaneously extend types 'A' and 'B'. Named property 'f' of types 'A' and 'B' are not identical.ts(2320) but AS will not.

@CountBleck
Copy link
Member Author

CountBleck commented Jan 16, 2024

By the way,

interface A {
    m: Object | null
}

interface B {
    m: Object
}

interface X extends A, B {
    // m: Object
}

isn't valid in TypeScript, but uncommenting that line will fix the error.

@HerrCai0907
Copy link
Member

isn't valid in TypeScript, but uncommenting that line will fix the error.

So at least we need to know what is correct and what is wrong firstly to avoid huge mismatch with TS.
Normally type system is very complex module which has lots of corner cases.
Maybe we can start from the most strict mode and forbidden each same name declaration and release limitation one by one to avoid publishing break change over and over.

@CountBleck
Copy link
Member Author

I believe the error is only emitted if the property isn't explicitly defined on the interface. Maybe some more digging is warranted though.

Also, another thing about the "simultaneously extend" error: for each conflicting property, it chooses the first interface with that property to be the first interface mentioned in each error (for that property), and the second interface is each of the remaining interfaces.

I can't explain it that clearly, so here's an example. x and y are the conflicting properties. For x, B comes first, so there are errors for B and C, as well as B and D. For y, C comes first, so there are errors for C and D, as well as C and E.

@HerrCai0907
Copy link
Member

So this PR still missing combination check when inheriting from difference base interfaces, right?

@CountBleck
Copy link
Member Author

Both of those things I described are part of that diagnostic, which I haven't implemented yet.

@lebrunel
Copy link

FWIW we're actually running this PR in our fork of assemblyscript, and we added a small number of extra diagnostics messages to our custom compiler for different interface scenarios. I can share our test cases if that would be helpful?

@CountBleck
Copy link
Member Author

@lebrunel that would be great, thanks!

@lebrunel
Copy link

The following is by no means exhaustive (we don't have a test for the simultaneous extending case mentioned above), but hopefully these are in someway helpful. At the very least you'll be able to write some tests that fail :P

// implementing a different method signature should fail
// Types of property `m` are incompatible.
interface A {
  m(): void;
}

class B implements A {
  m(n: u8): void {}
}
// implementing a different method signature from nested interfaces should fail
// Types of property `m1` are incompatible.
interface A {
  m1(): void;
}

interface B extends A {
  m2(): void;
}

interface C extends B {
  m3(): void;
}

class D implements C {
  m1(n: u8): void {}
  m2(): void {}
  m3(): void {}
}
// implementing a different method signature with compatible types should pass
interface A {
  m1(): A;
}

interface B extends A {
  m2(): B;
}

class C implements A {
  m1(): C { return this };
}

class D implements B {
  m1(): D { return this };
  m2(): B { return this };
}
// extending a different method signature should fail
// Types of property `m` are incompatible.
interface A {
  m(): void;
}

interface B extends A {
  m(n: u8): void;
}
// extending a different method signature from nested interfaces should fail
// Types of property `m1` are incompatible.
interface A {
  m1(): void;
}

interface B extends A {
  m2(): void;
}

interface C extends B {
  m1(n: u8): void;
}
// implementing a different field type with compatible types should pass
interface A {
  a: A;
  b: A | null;
}

class B extends Jig implements A {
  a: B;
  b: B | null;

  constructor(a: B, b: B) {
    super()
    this.a = a
    this.b = b
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants