[jsr294-modularity-eg] hide otherwise exported classes

[Alex Buckley]

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