Oh, I think I might have misread your question a little. Sorry 'bout that. It's difficult to suggest a perfect solution without knowing more about your actual use case, but I would probably go with one of these two approaches:
1) If the two types are basically different implementations of the same concept, where the abstract type can really capture the concept, I would not export either MA.T or MB.T. Rather, I'd export AbstractT, and a bunch of methods working on AbstractTs, and have all client code use only that, and be agnostic of whether it's really the implementation from MA or MB. This works well only if the two concepts MA.T and MB.T are so similar that all verbs that are related to them (i.e. all functions you might want to apply to them) are the same, so that you can just dispatch on the runtime type and get the job done. 2) If the two types are implementations of different concepts with some things in common, I'd rename them to make that fact clear; don't call them MA.T and MB.T, but rather MA.ThisT and MB.ThatT, For example, don't have `module Linear type Model end end` and `model Exponential type Model end end`, but rather two types `LinearModel` and `ExponentialModel` and export both. You'll avoid naming conflicts, and the actual intent of your code will be better communicated to the user (who might not know, or want to know, exactly which module the type was defined in). If neither of these approaches seem viable, can you give some more detail on what you're trying to do? On Monday, September 28, 2015 at 2:36:49 PM UTC+2, Christoph Ortner wrote: > > Tomas Lycken: I do this actually, but didn't mention it to not make the > question overly complicated. How does it solve my problem? My question was > about co-existence of MA.T and MB.T . > Thanks, > Christoph >
