[jsr294-modularity-eg] 294 EG conf call, 2009-04-29

[Bob Lee]

[off list]

On Fri, May 1, 2009 at 3:57 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:

> - Module-private members should be allowed in interfaces.
>

Please don't do this. Limiting interface members to public (not private,
package-private, protected, module) is a nice feature. If we allow
module-scoped members, we'll also have to allow package-private and
protected and possibly even private members (for nested interfaces), and in
all cases, it will be confusing when users can't implement interfaces
because they can't implement members that they can't even see. Of course,
entire interfaces can still be module-scoped.


> - 'package' should be allowed as an accessibility modifier.
>

Please don't do this. This feature doesn't carry its weight. We have one
obscure use case:

  public class module {
    module module();
  }

The question is, is module() a module-scoped constructor or a
package-private method that returns module? The answer is simple. It's the
same as it is today, a package-private method that returns module. It sucks
that you can't have a module-scoped constructor in this class, but it
doesn't suck badly enough to justify adding an explicit modifier for package
scope.

Adding an explicit package scope modifier will introduce two ways of doing
the same thing. Style wonks will require that you use "package" explicitly
everywhere to be consistent, and Java will become more verbose as a result.
I really like having a useful default accessibility modifier. Of course, it
would be nicer if private was the default, but at least package-private
isn't part of the published API.

In any case, being able to specify a module-scoped constructor in a public
class named "module" isn't reason enough to justify adding this language
feature.

Thanks,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090504/4207826b/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg