More Readable Use Site extension Methods for java

[Brian Goetz]

I get it.  But...no.

These "local" extension methods are indeed less intrusive than a more global 
use-site extension mechanism.  On the other hand, that makes them less useful 
as well.  (Yes, you're damned either way -- the global mechanism is 
philosophically objectionable, and the local mechanism doesn't really seem to 
pull its weight.)

There are already a huge pile of language and library changes slated for 
lambda.  We're looking to not increase the scope of change any further; every 
change carries risk, and the schedule is getting pretty darn short at this 
point.  So, this is an easy "no".

I realize everyone has a feature they would love to see.  Reality dictates 
that we say no to 99% of them.

On 12/7/2010 10:42 AM, Llewellyn Falco wrote:
>     However, we remain opposed to use-site extension methods because we believe
>     that the author of an API should remain in control of their API.  Allowing
>     users to monkey-patch in new functionality to existing types undermines this
>     demarcation of responsibility.
>
>     (A further problem with use-site extension methods is the lack of reflective
>     discovery.  Consumers of classfiles (such as non-Java compilers like JRuby, as
>     well as templating mechanism such as JSP EL) cannot easily find these
>     extension methods.)
>
>
> Extension methods as stated ALREADY exist. the only difference is that they
> can be applied after the "." which effects readability.
>
> Let me restate this. The only argument here is READABILITY.
>
> i have a blog about this here:
> http://llewellynfalco.blogspot.com/2010/09/extension-methods.html
>
> These type of methods aren't actually part of the object. It is just syntax to
> allow for readability. They don't give or takeaway any power from the
> "creator" of the object.
>
> As for readability, here's an example of  the difference between the current
> "reverse polish" notation enforced and the ability to write after the "."
>
> Current
> dividedBy(minus(times(add(1,2)3),1)4)
>
> Make sense?
> Easy to read?
>
> let's try after the "."
>
> 1.plus(2).times(3).minus(1).dividedBy(4)
>
>
>
> I believe there is a strong case that is more readable.
>
> llewellyn
>
>