[jsr294-modularity-eg] Simple Module System Proposal

[Peter Kriens]

Bryan,
Our key design goal for the SMS was to make 80% of the use cases  
simple and the remainder possible. That is, make simple things simple  
and allow more complex things.

So there seem to be two possibilities:

   - We have the wrong design goal, or
   - We do not cover 80% of the use cases

It is hard to see which of the two is your concern? If the coverage is  
your concern, could you propose use cases that should fall under the  
80%?

That said, I am a bit surprised with your last paragraph. In this you  
mention the following requirements:

         Requirement                        Before            SMS
	Simple syntax                      annotations++     fixed keyword
	In a single file                   module-info       module-info
	Compile-time error checking        mod. system       compiler
	Fidelity with the runtime          mod. system       VM
	Semantics                          mod. system       JLS
	Extending the compiler             yes               no

All these seem to be highly in favor of the SMS from a simplicity  
point of view?

Kind regards,

	Peter Kriens

On 10 sep 2009, at 02:21, Bryan Atsatt wrote:

> I agree with the idea of a standardized version syntax and with  
> defining semantics for the 'requires' directive (if possible :^);  
> however, I can't support this proposal. It trades off usability for  
> a form of purity, introducing considerable extra complexity for all  
> non-trivial use cases.
>
> This 'simple' proposal is anything but, turning two module systems  
> into *four*: simple-osgi, simple-jigsaw, full-osgi, full-jigsaw.  
> Syntax is common between the simple variants, but... bizarrely  
> contorted otherwise. Interoperation is possible between the simple  
> variants but not with the full ones. Compile time error checking is  
> possible with the simple variants but not the others, resulting in a  
> confusing, frail and ultimately unreliable feature.
>
> All so we can insist that a subset of module system semantics is  
> written down in a 'language' spec? Where a single, tiny step beyond  
> that subset forces a leap to a distant document/specification?
>
> The word "morass" comes to mind.
>
>
> I'm sorry if this all sounds harsh, but I'm in this to make  
> modularity more usable; to me this means simple syntax, in a single  
> file, with good compile-time error checking and fidelity with the  
> runtime. If that means we have to point at separate documentation to  
> define semantics, at least it will all be in one place.  And if it  
> means extending the compiler to leverage module-system  
> implementations, so be it; I'll be well satisfied that we made the  
> right tradeoff.
>
>
> _______________________________________________
> 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/20090910/7385a75e/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