-
Notifications
You must be signed in to change notification settings - Fork 246
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
Labels
Comments
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.
This should already be the case. I'm fairly sure I added checks to this effect. No? |
Can't seem to find a test for it though ;( |
My memory is that the checks only existed for things that start with |
Existing check (
Missing checks (
|
3 tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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.
The text was updated successfully, but these errors were encountered: