Prevent merge of duplicate classes in some cases

[Cécile Camillieri]

In some cases, for example when a concern is reused twice, classes that have not been mapped will be merged together by name. However it may happen that we don't want such classes that are not partial to be merged.

For example if the user reuses Authentication twice, the Session classes will be merged by the weaver in a single one. This causes the exception described in issue #384, but the problem here is that theses classes should not be merged together in the first place.

There are several ideas to explore in order to fix this issue:

• Maybe the check to know if two classes are duplicates of each other is not good enough.
• Maybe it's the concern's designer that should take in account this issue and make Session partial.
• A whole new concept could be used to describe that some classes should not be considered duplicates (something like instantiations cardinalities might be useful).

[Jörg Kienzle]

My view on this has always been that there should be no automated merging of model elements by name in the case of reuses. Automated merging should only happen when “extending”.

This would mean that when reusing Authentication twice, the weaver would “refuse” to weave when it realizes that in the woven model there would be two classes named Session, which is inconsistent. To solve this, the user would have to create two classes “Session1” and “Session2”, and map Session of the first reuse to Session1, and Session of the second reuse to Session2.

Of course this can be tedious. We could, for instance, do this automatically, i.e., for all user-defined, non-partial classes that are in a concern that is reused n times (n being more than one), automatically create n classes in the woven model called “Class”+NameOfReuseX, and create a mappings for them.

Would that work, or does anyone see a problem with that?

• J

[Cécile Camillieri]

Yes it seems like a good solution!

But I feel like in some cases we may still want to merge. For instance in Authentication there is this this AuthenticationException, and I don't really see why it should not be merged. Same goes for enumerations, it would seem strange to have two enums with different names and the same content. And what about implementation classes? For example in NetworkCommand there is an implementationClass for Socket, again I don't see why it should not be merged. I may be wrong though, and it would give more clarity to duplicate everything.

[Jörg Kienzle]

I think there should be no merge for user-defined classes. Implementation classes and enums that are identical should be merged.

AuthenticationException would be a user-defined class, so in the end there should be n of them. I think this makes sense, since one might want to catch one but not the other. The only reason I can think of that would make me instantiate Authentication twice is to have two separate authentication systems, like separate “levels” of security, where everything is duplicated (user/credential database, etc). In that case, I think it also makes sense to have different names for the exceptions thrown by the two separate systems.

• J