Proposal for extending functionality of default methods to allow general use

[Zhong Yu]

On Wed, Jan 30, 2013 at 4:02 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> In other words, while it's true that I could get the "same" effect by
>> just writing a method:
>>
>> static void printListSize(List<T> list)
>> {
>>     System.out.println("The size of this list is: " + list.size());
>> }
>>
>> and then just calling that method as needed, it would be *better*
>> (less burden on the programmer), if I could express that in terms of
>> an extension method on the List interface itself...
>
> You've sort of answered your own question -- you can do what you want,
> you just want a more convenient notation.  And the question is -- what
> is the cost of that programmer convenience.
>
> I think the key difference in perspective -- which leads us to different
> conclusions -- is about the meaning of "better".  (The pragmatic
> philosopher C.S. Peirce commends us to think not in terms of an abstract
> "better", but instead with an explicit "better for X".  Being explicit
> about this often cuts to the heart of many otherwise hard-to-resolve
> disagreements.)  As a programmer, you naturally think in terms of
> "better for the programming writing the code", since you are intimately
> familiar with all the things that get in your way when writing code --
> and reasonably so!  However, it is a core Java language design principle
> that:
>
>    Reading code is more important than writing code.
>
> There's also sorts of data that says that code is read many more times
> than it is written.  Anything that obfuscates the meaning of "x.y()" may

Agreed - overloading the "dot" is bad; maybe we can use another
operator, like two dots, for static extension methods, it'll be clear
to readers that this is a static method invocation.

> be convenient for the writer, but becomes a burden to the reader and
> maintainer.  So I prefer to think in terms of "better for the ecosystem
> as a whole."  If that means many readers benefit by the inconvenience of
> some code writers, that's a tradeoff I'll make any day.  And since we're
> all readers and writers of code, its not really like this hoses one
> group of developers at the expense of another.
>
> You are correct that many libraries are less than perfect.  And that
> does make difficulty for programmers just trying to get through their
> day.  As someone who programs as much as my job responsibilities will
> let me, I am not unsympathetic to this!  But the cure should not be
> worse than the disease.
>
> Cheers,
> -Brian
>
>