Use "default" keyword for default visibility.

[Jeremy Manson]

I can see Alex's argument.  I would imagine that that belongs in the
modules JSR, though.

Jeremy

On Sun, Mar 1, 2009 at 1:29 AM, Mark Mahieu
<mark at twistedbanana.demon.co.uk> wrote:
> Regarding use of 'package' as a modifier, Alex Buckley mentioned it as a
> possibility a while back on his blog, in connection to the modules JSR:
>
> http://blogs.sun.com/abuckley/en_US/entry/a_wrinkle_with_module
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4456057
>
> I have no idea whether that's a current consideration, however.
>
> Mark
>
>
> On 1 Mar 2009, at 09:15, Jeremy Manson wrote:
>
>> Could you dig up the example?  It is hard to see why this is
>> compelling without it.
>>
>> I think it would have to be a warning instead of an error, because
>> otherwise, it is a change that breaks backwards compatibility (i.e.,
>> it makes old stuff not compile).  I think there is a reasonable sized
>> danger in introducing so many warnings for a change this small; people
>> are likely to ignore / get upset about the flood of warnings that
>> their compiler is suddenly generating.
>>
>> Did you consider the use of annotations as an alternative?  In code
>> that I write, if something has package-private visibility, it is
>> usually for testing; Google has a @VisibleForTesting annotation that
>> we use.
>>
>> Also, why not use the package keyword?
>>
>> Jeremy
>>
>> On Sun, Mar 1, 2009 at 1:01 AM, Adrian Kuhn <akuhn at iam.unibe.ch> wrote:
>>>
>>> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>>>
>>> AUTHOR(S): Adrian Kuhn
>>>
>>> OVERVIEW
>>>
>>> Allow the "default" keyword to be used as modifier for default
>>> visibility. In strict mode, missing use of default is a warning /
>>> error, in compatibility mode both the current (ie no default keyword)
>>> and the new syntax are accepted.
>>>
>>> FEATURE SUMMARY: Use "default" keyword for default visibility.
>>>
>>> MAJOR ADVANTAGE: The missing keyword for default visibility breaks the
>>> symmetry of visibility modifiers. Since it is the only implicit
>>> modifier, omitting any of the three explicit modifiers by mistake may
>>> be the source of unexpected behavior and thus hard to track down bugs.
>>> (There was an example on a blog post recently, but I cannot find it
>>> know).
>>>
>>> MAJOR BENEFIT: Symmetry of visibility modifiers is restored.
>>>
>>> MAJOR DISADVANTAGE: Two ways to express the same thing (in
>>> compatibility mode).
>>>
>>> ALTERNATIVES: Using a comment such as /* default */ is not an
>>> alternative since such comments are not processed by the compiler.
>>>
>>> EXAMPLES
>>>
>>> public class C {
>>>       default Field f;
>>> }
>>>
>>> SIMPLE EXAMPLE: See above.
>>>
>>> ADVANCED EXAMPLE: None.
>>>
>>> DETAILS
>>>
>>> SPECIFICATION: "default" is already a keyword and introducing it as a
>>> new visibility modifier is save, it does not lead to ambiguous grammar.
>>>
>>> COMPILATION: Same as now for implicit default visibility.
>>>
>>> TESTING: Same as now for implicit default visibility.
>>>
>>> LIBRARY SUPPORT: None.
>>>
>>> REFLECTIVE APIS: None.
>>>
>>> OTHER CHANGES: None.
>>>
>>> MIGRATION: Compatibility mode allows both, implicit and explicit
>>> default visibility, to be used at  the same time.
>>>
>>> COMPATIBILITY
>>>
>>> BREAKING CHANGES: None.
>>>
>>> EXISTING PROGRAMS: Work fine in compatibility mode.
>>>
>>> REFERENCES
>>>
>>> EXISTING BUGS: To my best knowledge, none.
>>>
>>> URL FOR PROTOTYPE (optional):
>>>
>>>
>>>
>>>
>>
>
>