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

[BJ Hargrave]

#3 seems best.

There is also the specific issue of how values for keys which are defined 
by a module system are validated. For example, the value of the version 
key will need to conform to the grammar mandated by the module system.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Bryan Atsatt <bryan.atsatt at oracle.com>
To:
JSR 294 Expert Group <jsr294-modularity-eg at cs.oswego.edu>
Date:
2009/04/30 16:00
Subject:
[jsr294-modularity-eg] dependency declaration syntax...
Sent by:
jsr294-modularity-eg-bounces at cs.oswego.edu



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090506/195232f1/attachment.html>