[jsr294-modularity-eg] hide otherwise exported classes

[Eugene Vigdorchik]

Michal,

I don't see it as complicating the syntax, it is just a feature opposite to declaring member packages. 
To justify the addition of hide statement, consider a use case when the user wants all of the classes to be exported but one.
Without the ability to hide, he would need to put n - 1 classes in the superpackage file. Furthermore, in the process of
superpackage evolution the superpackage file would need to be updated every time a new class is created (Also is it ok to mention
nonexistent classes in superpackage?). As for the danger of understanding what is exported,
I rather think it is not the list of exported classes that is interesting to the user of the superpackage, but the fact if the class
he wants to use is exported. And this is much easier to understand when the file to read is shorter. Also users of the IDEs would
benefit from their tool automatically analyze superpackage file, and report about the visibility, so in general they would not need
to read superpackage file at all.

Just my 2c
Eugene.

> -----Original Message-----
> From: jsr294-modularity-eg-bounces at cs.oswego.edu 
> [mailto:jsr294-modularity-eg-bounces at cs.oswego.edu] On Behalf 
> Of Michal Cierniak
> Sent: Wednesday, April 11, 2007 9:39 PM
> To: JSR 294 Expert Group
> Subject: Re: [jsr294-modularity-eg] hide otherwise exported classes
> 
> (Changing the subject, so that we have a separate thread for 
> each issue).
> 
> On 4/11/07, Eugene Vigdorchik <ven at jetbrains.com> wrote:
> > Next it seems that having only the possibility to export 
> > classes/subpackages is not enough, it should be possible to 
> hide otherwise exported classes.
> > Thus already having a package in the superpackage the user 
> should be 
> > able to hide a certain class in it without listing all the classes 
> > left explicitly in the superpackage.
> 
> Just to make clear, an example for this suggestion is (using 
> syntax made up for this email):
> export package P;
> hide class P.C;
> is this correct?
> 
> It is an interesting proposal.  However, as you will probably 
> see in future discussions, I have a general bias towards 
> simplicity and in this particular case, I don't see enough 
> value in allowing this extra complication.  While it might 
> make your life easier in some cases, I see a danger that 
> understanding what is really exported might suffer (this is 
> of course just based on my intuition).
> 
> Michal
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>