[jsr294-modularity-eg] hide otherwise exported classes

Fri Apr 13 06:21:18 EDT 2007

I support this feature. It would simplify enabling JSR 291 to exploit JSR 
294 because of JSR 291's package-based import/export syntax (with class 
level filters).

Also, 'hide' seemed to be a valuable feature of the MJ paper and prototype 
that IBM Research did ([1] - worth reading for background as it covers 
very similar ground to JSR 294).

Glyn

[1] http://citeseer.ist.psu.edu/694340.html

Alex Buckley <Alex.Buckley at sun.com> wrote on 12/04/2007 21:59:34:

> I am quite sympathetic to 'hide'. It's a small feature that is strictly 
> local in its effects, i.e. it relates to just the exported type list and 

> not any other artefact like nested superpackages. As long as hide's 
> parameter is a list of type names and not some monster regex-aware 
> expression, I'd support it.
> 
> Alex
> 
> Bryan Atsatt wrote:
> > 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
> >> 
> >> 
> > 
> > 
> > _______________________________________________ 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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070413/06a9a759/attachment.html 