[jsr294-modularity-eg] hide otherwise exported classes

[Michal Cierniak]

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
>