Cleanup deprecated types

[tortmayr]

Ensure that deprecated types are isolated and don't leak into non-deprecated definitions. => Consistently use definitions from sprotty protocol in non-deprecated classes,functions or type definitions.

[spoenemann]

Thanks!

This reminds me of a thought: shall we rename the internal model classes such as SNode, SEdge in order to avoid the name conflict with the protocol interfaces? This name clash is rather confusing for users (where do I need to import that from?)

Example: SNodeImpl, SEdgeImpl etc.

[tortmayr]

Thanks!

This reminds me of a thought: shall we rename the internal model classes such as SNode, SEdge in order to avoid the name conflict with the protocol interfaces? This name clash is rather confusing for users (where do I need to import that from?)

Example: SNodeImpl, SEdgeImpl etc.

I aggree, we definitely have to find a cleaner solution than the way we handle it right now. However, I'm not sure if renaming the internal model is the way to go here. This would introduce a major API break and affects a large part of the code base.

We could also go the other way round and rexport sprotty-protocol as part of sprotty with some modifications i.e. renaming the clashing interfaces from sprotty protocol. (e.g. SModel -> SModelSchema). This would also mean users can simply import everything directly from sprotty and we don't break the existing API.

Pros and Cons for both approaches so we probably should discuss & handle this in a follow-up.
It might also be time to remove the deprecated action types as they also contribute to this whole name clashing confusion.

[spoenemann]

This would introduce a major API break and affects a large part of the code base.

That's true. But I would prefer such an API break for the transition to version 1.0 over keeping a confusing naming scheme for years to come. I'm not sure re-exporting with different names is the best option – in the worst case, that would increase the confusion.

[dhuebner]

@tortmayr
PR is approved. Should we merge it?

[tortmayr]

@spoenemann I have rebased the change and addressed the two open comments/issues.
We should probably handle the renaming oft the internal model classes with a follow-up PR.

[spoenemann]

Thanks!