Defender Extension Methods -- Resolution and Invoccation

[Stephen Colebourne]

On 5 August 2010 01:28, Brian Goetz <brian.goetz at oracle.com> wrote:
> Your are being tripped up by the belief that most Java users are like you!
> (And we all know there's only one of Neal.)
>
> The vast majority of the 12M+ Java developers will probably never use this
> feature.  But doing it this way saves us from imposing what will look like a
> significant paradigm shift on them, which would certainly rock their world for
> little benefit.

I think this is not actually going to be so. Adding a defender method
will I suspect be a quite common operation for the 12+M devs.
Certainly not all, but enough. This statement seems to be at the heart
of the tension of not including the implementation in the interface
(which is the /natural/ place to expect to find it - static methods
and helper classes are essentially just a horid hack). BTW. I think
the hangup over the meaning of interface vs class is overblown.

Don't get me wrong, this is better than what we have today. And the
ability for implementations to supply their own implementation is
essential.

More broadly, design patterns are one way that languages evolve.
Consider the enum pattern to language feature in Java. With this
feature, there is an obvious pattern:


public interface Foo {
  getWorld();
  extension checkWorld() default Utils.checkWorld(Foo);

  static class Utils {
    void checkWorld(Foo foo) {
      if (foo.getWorld().isValid() == false) {
        throw new RuntimeException();
      }
    }
  }
}

Certainly, if this feature goes in as is I will be writing up and
describing this as the default way to write new static helper classes
targetted as extension methods.

So its a pattern. Just boilerplate.

<sarcasm>But thats OK, as no-one expects anything but boilerplate from
Java</sarcasm>

Seriously, the benefits of the open process are a greater ability to
see into the future. Consider this an indication of what JDK 8/9 might
contain...

Stephen