IR does not support multiple external types
Although the language spec allows for the definition of multiple external types, the IR only has space for a single external type which conforms to the java naming convention.
I think if you're going to rev the version of the IR that it'd be worth considering a next step of removing external types.
@markelliot I don't see a ton of upside of removing external types and I think there are some quite significant downsides.
If the intention is to encourage people to use first-class conjure features, I'd prefer to just hide the functionality behind a feature flag so people have to intentionally opt-in to use it.
External types were pretty important when migrating existing internal jaxrs services to Conjure - removing them would make adopting Conjure much trickier for anyone who has lots of existing jaxrs services.
I thought we had discussed this at length? Part of the main value prop of Conjure is consistent behavior across languages. With external types, this is no longer something we can guarantee.
@uschi2000 the issue of removing external imports has come up lots of times (I know you're keen to see the back of them), but I still think the tradeoffs of making such a change still needs to be explicitly written up and appropriately broadcast to users!
I think ease of migration for existing jaxrs services was an attractive feature of Conjure, and I have personally relied on this to migrate a big internal service. I don't think it's really fair to make design decisions assuming entirely greenfield use-cases and I think we still need to consider the brownfield ones.
I consider external imports a bit like rust's unsafe, in that conjure def with zero external imports are more desirable, but it would be net negative to remove it entirely.
Regardless of our stance on external types, the current implementation (and associated documentation) is incorrect and has unexpected results. The language allows for you to define multiple external types in a map keyed by language, but the implementation will just take one of the keys and use that as the external reference. We should at least fix this so that the behaviour is consistent and documentation reflects reality
Not sure where the appropriate place to have the debate on #90 is -- this ticket is linked to #90 as one of the major breaking changes.
Re: incremental transition: one could transition the other way: instead of converting to services first, convert objects first. External types existed for legacy migrations to cover early days of transition when Conjure was not full-featured.
To lean into the trade that @uschi2000 suggests: if we continue to support external types, we must make them full featured across all languages and demand universal language support for defined external types, or we're failing to meet critical guarantees. What would such support look like, in reality?