Limitation of Interfaces

[Nir Lisker]

(Sorry about forgetting the subject line, I added it now)

Actually protected methods wouldn't save me either since they are part of
the public API. I either need "protected but not public API" or
package-private, which is less suitable but probably easier. I think that
in this case private fields in interfaces will be more ideal. Good to know
that this is something that can be changed in the future, even if it's not
on the drawing table yet.

On Tue, Jan 18, 2022 at 9:52 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> The full range of accessibilities for interface methods was discussed at
> some length during the design process.  Interfaces were extended to support
> private methods, which leaves questions hanging over whether protected and
> package-private methods could also be supported in interfaces.  (Also, it's
> limiting that private fields/classes are not permitted in interfaces, which
> would be very useful, and this was mostly an oversight, which will probably
> be fixed eventually.)  What you want -- protected methods in interfaces --
> are more complicated than it might first appear, because the semantics of
> "protected" are also more complicated than they first appear.  It is
> probably possible but would surely be a lot of incremental complexity for
> not as much incremental expressivity.
>
>
>
>
>
> On 1/18/2022 2:25 PM, Nir Lisker wrote:
>
> I'm not advocating for multiple inheritance or new visibility modifiers
> (though here there is a broader issue where library designers want a
> "protected but not public API" kind of visibilit), but I would like to not
> need to copy-paste the same code everywhere, whatever the solution might
> be. Is there a solution?
>
>
>