Import Aliasing

[dselman]

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

import { Document as AccordDocument } from org.accordproject.commonmark

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.

[kailash360]

@dselman @mttrbrts

I went through this issue, and it looks like we can create a separate field in the JSON schema as alias to define the alias name for the property. We will always give priority to the alias over the actual considering that it will prevent the conflicting behavior. In the parser we can add the feature to check for the as <alias> and use that value globally in the file. Let me know if this sounds to be a good approach to start with.

[kailash360]

Also, considering that it is one of the GSoC ideas, I would love to work on it.

[salujajaskeerat]

To implement the alias import, I am thinking of implementing the syntax suggested by @dselman above.

Syntax : import [email protected].{ Type as t ,...}

• Allowing optional aliases for types in import statements.
• Example import org.accordproject.commonmark.{ document as doc1 , cmk } import org.accord project.utilities.{ document as doc2 , utl }

In the above types, cmk, utl are not aliased.

[mttrbrts]

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?

[salujajaskeerat]

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.

[ekarademir]

Some test cases to consider

import com.example.foo.{as as as}

import com.example.foo.{As as as}

import com.example.foo.{Document as Doc1, Doc2}
import com.example.bax.{Document as Doc2}

[sanketshevkar]

Another option, would be : instead of as similar to what JS does with aliasing deconstructed object properties. import com.example.foo.{Document: Doc1, Doc2}

[salujajaskeerat]

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 : import ns.{ Type : t ,...} where ns:QualifiedNameSpaceDeclaration.

[salujajaskeerat]

In the Technology-wg, as discussed with @mttrbrts, aliasing with the keyword as is more readable compared to : or =, so the decision is to make as a local reserved key-word in the import statement and not a global reserved key-word. It would still be backwards-compatible.