[External] : Limitation of Interfaces

[Brian Goetz]

Don't forget that interface fields are always static, so this may not 
help as much as you think.

On 1/18/2022 3:03 PM, Nir Lisker wrote:
> (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?
>
>