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

[Daniel Leuck]

Yes - This is what I was suggesting, except that the values would be
literals for the types allowed by annotations, so #3 would actually be:
    requires package name="bar", version="1.1", vendor="acme",
goodIdea=true;

This is a trivial task for the compiler, and allows extension in the future
if we want to introduce some of the ideas Bob put forward (without
committing to such a course of action.)

Cheers> Dan

On Thu, Apr 30, 2009 at 9:58 AM, Bryan Atsatt <bryan.atsatt at oracle.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090430/d1d06dc9/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg