brian.goetz at oracle.com
Mon Apr 15 15:12:51 PDT 2013
We probably won't know what the first rule is for quite a while, but I
think the line of reasoning you're following here is a good one to
explore, and may well lead somewhere good.
Regretfully, I can immediately think of a countervailing design force;
that interface instance methods are inherited and interface static
methods are not. (This was a deliberate choice; the EG viewed the
inheritability of static methods in classes (or the ability to invoke
them through instances) to be a bug, and one which would have even more
harm under multiple inheritance than under single inheritance.) As
such, adding new instance methods after-the-fact has a higher risk of
clashing with existing methods in existing implementations, or simply
being a mismatch by the time you get far enough down the inheritance
tree, because every subtype has to take it. Adding a static to an
interface can't interfere with anything down-tree.
But I think you're headed in the right direction.
On 4/15/2013 5:54 PM, Stephen Colebourne wrote:
> On 15 April 2013 22:41, Brian Goetz <brian.goetz at oracle.com> wrote:
>> An example of a method at the other end of the spectrum is
>> Collections.rotate(List, int). Sure, this is useful when you need it,
>> but it just isn't that important, and weighing down an interface with
>> 5000 lines of additional code (OK, Collections is only 4700 LoC) really
>> clogs up the Collection interface.
> Perhaps there is a semblance of a first rule here.
> - Collections.rotate(List, int) - static
> could now be:
> - List.rotate(List, int) - static
> but that would just look and behave weirdly, because it should be
> - List.rotate(int) - instance
> But, most of us would agree that an instance method for rotating
> probably isn't justified. Thus it is also not justified as a static
> method on the same interface.
> The rule is therefore along the lines of "don't add a static method
> where one of its arguments is the same type as the interface and the
> methods purpose is to operate on that argument. Either use a default
> instance method on the interface, or keep it in a separate utility
More information about the lambda-dev