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

Ensure Data Types have a "pure" inheritance tree #287

Closed
dstufft opened this issue Oct 30, 2018 · 4 comments
Closed

Ensure Data Types have a "pure" inheritance tree #287

dstufft opened this issue Oct 30, 2018 · 4 comments
Assignees
Labels
effort/small Small work item – less than a day of effort p0

Comments

@dstufft
Copy link
Contributor

dstufft commented Oct 30, 2018

Data Types and "Normal" interfaces need to have distinct inheritance trees for the Python generated code to function. IOW, a data type can't inherent from a non data type, and a non data type can't inherit from a data type.

#271 should solve the case where a data type cannot inherit from a non data type, however it's still the case that a non data type can inherit from a data type. IOW this currently is accepted:

export interface SomeProps {
    foo: str
}

export interface ISomething extends SomeProps {
    bar(): void;
}

However, that could would cause an error in Python, because a "normal" interface cannot inherit from a data type, so we should reject that in the JSII compiler.

@fulghum fulghum added the p0 label Mar 12, 2019
eladb pushed a commit that referenced this issue Mar 19, 2019
Respect the `@internal` jsdoc tag on types and members. Any type of member marked internal will not be exposed in the API of the module and in .d.ts. files (through `--strip-internal`).

Members (properties/methods) that are marked as `@internal` must also have an underscore prefix (i.e. `_myMethod`) and vice versa in order to ensure that implementers or subclasses won't modify  accessibility.

If a class implements (or an interface extends) an internal or private interface, that interface is erased from the implementer's API. So it is possible to use internal interfaces as bases, while still maintaining API integrity (related to #287).

Fixes #388

BREAKING CHANGE: member names that begin with underscore now must be marked as "@internal" in their jsdocs, which will cause them to disappear from type declaration files and jsii APIs.
@rix0rrr
Copy link
Contributor

rix0rrr commented Mar 25, 2019

This should already be the case. I'm fairly sure I added checks to this effect. No?

@rix0rrr
Copy link
Contributor

rix0rrr commented Mar 25, 2019

Can't seem to find a test for it though ;(

@dstufft
Copy link
Contributor Author

dstufft commented Mar 26, 2019

My memory is that the checks only existed for things that start with I, but that things that don't start with I could still exhibit this problem.

@RomainMuller
Copy link
Contributor

Existing check (jsii already rejects):

  • An interface extending another one which is not a struct, cannot be a struct.

Missing checks (jsii will happily proceed):

  • A class may not implement a struct interface
  • A regular interface may not implement a struct

RomainMuller added a commit that referenced this issue Apr 2, 2019
Expected failure cases:
- [X] An interface extending another one which is _not_ a struct, _cannot_ be a struct.
- [x] A class may not implement a struct interface
- [x] A regular interface may not implement a struct

Fixes #287
@fulghum fulghum added the effort/small Small work item – less than a day of effort label Apr 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/small Small work item – less than a day of effort p0
Projects
None yet
Development

No branches or pull requests

4 participants