Backend-specific dependencies

[FroMage]

We need a way to say that backend JVM depends on those modules, but backend JS on those.

[tombentley]

Once we have a way to specify that a compilation unit is only for a particular back end (#500), this could be done by allowing the dependencies of a module to be declared 'outside' the module descriptor some how. For example using the source-java suggestion I made in #500, if the source directory contained the module.ceylon (which would contain the common dependencies) then the source-java directory could contain some compilation unit which added to those dependencies. This other compilation unit would only be allowed to add dependencies, not specify the module name or version.

Would you be allowed to export such backend specific dependencies?

[FroMage]

I think with the implementation of #500 we could define annotations for backend-specific imports and keep them all in the single module.ceylon file:

module foo '1' {
 import bla '1';
 jvm import bli '2';
 js import foo '1';
}

[FroMage]

BTW, this would be trivial to implement.

[gavinking]

I think this makes sense. Of course, it's only 1/2 of the problem. We still need to be able to define a module which has different underlying implementations for different backends. This feature, on its own, is almost useless. The hard bit is how to define a platform-independent module that makes use of platform-specific code.

[FroMage]

Well, go and tell us to go ahead on #500 then ;)

[gavinking]

We will solve this and #500 for Ceylon 1.1. Not for Ceylon 1.0. Sorry.

[gavinking]

I'm closing this issue. AFAICT, it doesn't propose anything that is not already provided by optional. If the functionality of optional should be enhanced in some way, please submit a new issue for that, with a proper definition of what needs doing.

[FroMage]

What? This is not about optional, unless you define what its semantics are to retrofit this issue. We discussed situations where for example the JVM backend would require module X (jvm-only) and Y (cross-backend) while the JS backend would require module Z (JS-only).

Also optional would never produce an error if the module is missing, and in the case of multi-backends we surely want to make sure the dependencies exist.

[gavinking]

What? This is not about optional, unless you define what its semantics are to retrofit this issue. We discussed situations where for example the JVM backend would require module X (jvm-only) and Y (cross-backend) while the JS backend would require module Z (JS-only).

All of which cases are already handled by judicious application of optional.

Also optional would never produce an error if the module is missing, and in the case of multi-backends we surely want to make sure the dependencies exist.

Ok, fine, so let's enhance optional to specify that a dependency is required for a certain platform. Sounds easy enough to do.

[quintesse]

Can't we reuse the platform annotation you just suggested in #500 ?

[FroMage]

All of which cases are already handled by judicious application of optional.

No, because optional ATM makes the module visible to every unit if it happens to be resolvable, and not just to certain backends.

Ok, fine, so let's enhance optional to specify that a dependency is required for a certain platform. Sounds easy enough to do.

Well, perhaps, even though I have a feeling this will end up meaning not required for backend X which is a negative I don't quite like.

But if you agree optional as it is is not enough, let's reopen this issue.

[FroMage]

platform would work, but that's essentially the original proposal, no?

[gavinking]

Moving to 1.2.

[quintesse]

I think this can be closed now. Any remaining problems can be put in their own issues.