[jsr294-modularity-eg] dependency declaration syntax...

[Alex Buckley]

Regarding #3 and #4, it's hard to imagine a dependency which doesn't 
have a target (name and optionally version). If granularity 
conventionally gets its own term, the target should too:

   requires package bar @ [1.0,2.0) flag1 k="v" flag2 ;

   'requires'  ID   ID ['@' VER]  ( ID ['=' '"' ID '"'] )* ';'

To validate the ID/VER terms, a compiler passes them to an API along the 
lines of 
http://cr.openjdk.java.net/~mr/jigsaw/api/java/lang/module/ModuleSystem.html

Alex

Bryan Atsatt wrote:
> We have now discussed a number of options for keyword (requires, 
> provides, etc.) operand syntax:
> 
>    requires <operand>;
> 
> I thought I'd try to enumerate the options so far...
> 
> 1. Opaque string:
> 
>    requires foo at 1.3;
> 
> 2. Granularity + opaque string:
> 
>    requires module foo at 1.3;
> 
> 3. Granularity + unbounded key/value strings:
> 
>    requires package name=bar, version=1.1, vendor=acme;
> 
> 4. Granularity + bounded, typed key/value pairs (annotation using 
> lowercase and without leading "@"):
> 
>    requires package(name=bar, version=1.1); // Really @package.
> 
> 
> (We also discussed an "unbounded, typed key/value pairs" variant, 
> re-using just the annotation style syntax, but... Without a type 
> declaration mechanism, we would be in the inference business; I don't 
> think we want/need to take that step).
> 
> 
> For each operand type, we need to consider how it would be reified in a 
> ModuleInfo class. I expect that for each keyword, we will need a method 
> that returns a Set<T>, where T is the operand type, e.g.
> 
>    public Set<String> getRequires();
> 
> for the opaque string case (1). For cases 2 and 3, we would need to 
> create a new descriptor type to wrap the granularity and the string or 
> key/value strings. Case 4 seems to require a return type of Object, 
> necessitating a downcast.
> 
> 
> I believe one constraint on the design space here is that a key/value 
> syntax needs to be unbounded: OSGi supports arbitrary attributes on 
> dependency declarations. This would imply a hack in the annotations case 
> (e.g. name=bar, version=1.1, attributes="key1=value1, ...").
> 
> And while I do like the idea that annotations provide an easily consumed 
> grammar, the extra complexity here does not seem worth it (even aside 
> from Alex's concerns about compiler difficulties).
> 
> So far, I think 3 provides the best balance of 
> functionality/clarity/simplicity/extensibility.
> 
> // Bryan
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg