[jsr294-modularity-eg] hide otherwise exported classes

[Bryan Atsatt]

Clearly the single non-exported class is a corner case, but just as obviously this is a continuum. If the number of classes in a package is small, explicit declarations will not be too painful, either way. But Eugene's point seems quite valid to me for large packages. For maintainability, we should strive for syntax that allows the *fewest* explicitly named classes:  

  public package P;  // Entire package "exported".
  private class P.C1, P.C2, P.C3; // .. except C1-3

And the inverse case:

  public class P.C1, P.C2, P.C3; // Only C1-3 "exported" from P.

// Bryan

> -----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: Thursday, April 12, 2007 10:19 AM
> To: JSR 294 Expert Group
> Subject: Re: [jsr294-modularity-eg] hide otherwise exported classes
> 
> Hi Eugene,
> 
> I wasn't worried about syntax at all!  Perhaps the word "simplicity"
> used by me was too broad?  I meant something like "easy to 
> reason about", "having a simple conceptual model" or 
> something to this effect.  I agree with you that we may make 
> it very easy to express syntactically but the question is 
> will people who look at a declaration that enables some 
> things but disables others be confused?
> Take regular expressions as an example.  The basic syntax may 
> be straightforward but when you look at a more complex regex 
> you might be confused.
> 
> Of course this is just my opinion and it is not based on any evidence
> -- just pure intuition.   I don't feel super-strong about this issue
> but FWIW I am not convinced by your example -- to me it looks 
> like a corner case that we shouldn't use to justify adding features.
> 
> So, does anyone else on the EG have an opinion?
> 
> Michal
> 
> On 4/12/07, Eugene Vigdorchik <ven at jetbrains.com> wrote:
> > 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
> > >
> >
> > _______________________________________________
> > 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
> 
>