Re: Protected and package in iterface

tam@milkyway.gsfc.nasa.gov wrote:


This was no "workaround". The only difference between what Java does and what
you want is that Java makes the whole interface, say, package-private. That
does exactly what you want, make the methods of that interface available only
to the package, with less code than if one had to mark every method.

It also keeps the self-documenting nature of 'interface' intact - that an
interface defines the public face to a type, the part others can see. If
that's not what you mean to do, then an interface is the wrong thing to use.
Private, package-private and protected methods exist for the purpose of
implementation, yes, implementation, not contract, and therefore belong in a
class, for you, an abstract class, as was stated waaay upthread.

It would be silly and damaging to specify implementation in an interface.
It's against their very raison d'tre.

My code points out how very easy it is - easy! - to contain the effects of an
interface to package level, using three different common Java idioms - a
top-level type declaration, a nested type declaration, and an anonymous inner
declaration. All three idioms effortlessly contained their effects to package
level in a way that you call a "real cost", "restriction", and that you have
"not seen a corresponding benefit".

The cost is zero. The benefit is that interfaces perform their architectural
role of specifying a contract, only, and that their effect can be contained to
arbitrary levels of protection so transparently that you misd-attribute the
complexity of an inner-class declaration to the lack of containment of the
interface. The interface was so well contained that its contained nature was
invisible to you. It really doesn't get any more effortless than that.

Unlike your approach, where one has to wonder method by method what the
containment level is. Java's approach is much simpler, to the point where the
effort vanishes altogether.

--
Lew