-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
Import Aliasing #480
Comments
I went through this issue, and it looks like we can create a separate field in the JSON schema as |
Also, considering that it is one of the GSoC ideas, I would love to work on it. |
To implement the alias import, I am thinking of implementing the syntax suggested by @dselman above. Syntax :
In the above types, |
This looks like a strong design to me and should be familiar to TypeScript / JavaScript / Python developers. A more C#-style approach would use namespace aliasing, although this could become confusing if users tried to use it to alias types too. It's likely that this would also force us to allow fully-qualified references to types throughout CML, rather than using short-names as we do today. Are there any other alternatives that we should consider? |
Yes the approach we are looking for is close to the typescript syntax. A more C#/C++ style approach , i think is more relevant for aliasing namespaces . Do we want to alias namespaces also ? using alias=namespace I believe this approach would require more syntax changes compared to the above design. |
Some test cases to consider
|
Another option, would be |
Since we don't have the keyword 'as' already defined in the concerto, using 'as' for aliasing types would cause breaking changes and require extra handling at the parser level of the code. I think @sanketshevkar's recommendation to use ':' would solve the above issue, as ':' is already a reserved keyword in concerto and hence won't be matched with an identifier. Other options could be '='. updated Syntax : |
In the Technology-wg, as discussed with @mttrbrts, aliasing with the keyword |
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
Feature Request ๐๏ธ
Allow imported types to be aliased to prevent name collisions.
Use Case
Allows a namespace X to import types from namespace Y that have the same names as types already present (or imported) into namespace X.
Possible Solution
Context
In general as models become larger and edited by distributed teams it is impossible to ensure name conflicts do not occur across namespaces.
Detailed Description
Allow name aliasing during imports. Alternatively we could support using fully-qualified names for properties.
The text was updated successfully, but these errors were encountered: