Extension methods vs. JSR 292 [Was: Re: Extension methods vs. Traits]

[Daniel Latrémolière]

>> I would like to understand the final paragraph of the proposal where you are
>> saying that the traits are much more significant change than extension methods
>> to the language and VM.
>>     
> >From a strictly technical standpoint adding traits might not be a (much?)
> more significant change than adding extension methods.
>
> >From a conceptual standpoint, however, adding traits to the language is
> a hugely significant change -- much more significant than adding lambda
> expressions.
>   
As new Java knowledge required for programmer, I am OK with the
knowledge complexity of traits, given traits will probably need to be a
third type like interface (but not a contract) and class (but only one,
partly independent, part of implementation without state). A good and
very useful implementation will probably need some others changes, like
"import MyClass with MyTrait1, MyTrait2;". It is reasonable for me,
given current Java7 roadmap, to not include it.

Thanks for the response and details, ... then another question between
extension methods and JSR 292.

> (Extension methods, by contrast, are just a fancy new
> variant of static imports.)
>   
Given extension methods are a new Java syntax, I would prefer if fancy
variants are only in IDE and doesn't change Java language (even if it is
not available for programmers who are not using IDE but can understand
better the real Java language). Reading will be slightly more complex
because it will be a static call to another class, but cleaner.

Then, I have nothing against adding annotations for driving suggests of
IDE, like this:
@DeclarationSiteExtension(methodName="sort",
targetClass="java.util.Collection", targetMethod="sort")
public interface List<E> extends Collection<E> {
...
}
if IDE write call in Java source code as "Collections.sort(list);".
You can even add support of this annotation in javadoc if you like it,
for helping user by giving him useful methods references for using his
List instance.

---------- If you want real extension methods:
If you want a source code of the call like "list.sort();", I would
prefer if this call becomes a short syntax for a more common
invokedynamic call (JSR 292) [3] using another separator than '.' (like
':' in following example), even if IDE add automatically the static
call, to the method registering JSR 292 call sites in linkage, using new
attributes in preceding @DeclarationSiteExtension annotation [4] or
user's configuration for use-site extensions (because use-site
extensions are possible with the same syntax/changes).

// Example for better understanding
public MyClass() {

      // added by IDE when making call expression to the extension
      // of List (using the annotation of List).
      static {
Linkage.registerBootstrapMethod(CollectionsExtensions.class,
"addListExtensions"); }

      public void myMethod(List<E> list) {
          list:sort(); // use ':' and not '.'
         // compiled with invokedynamic bytecode like
         // InvokeDynamic.sort(list);
      }

}

package java.util;
public class CollectionsExtensions {

      public static void addListExtensions(CallSite site, Object... args) {
         assert(args[0] instance of List);
         switch(site.name()) {
             case "sort":
                 assert(args.length == 1);
                 MethodType sortType = MethodType.make(void.class,
List.class);
                 MethodHandle sort =
MethodHandles.findStatic(Collection.class, "sort", sortType);
                 site.setTarget(sort);
             break;
         }
      }

}

[3]: Eat your own dog food. (Or more seriously reuse as much as possible
current linkage changes allowed by JSR 292 and why inventing a new
specific syntax?).
[4]: This will need these two new attributes to declaration-site annotation:
@DeclarationSiteExtension(declaratorClass=CollectionsExtensions.class,
declaratorMethod="addListExtensions")

My personal conclusion: An interface as a contract means that
implementers expects no changes in contract, then all user's features
doesn't need to pollute the contract: it is not the problem of
implementer. I only see annotations (because without effects on code by
Java definition) as possible room for helping users of interface and
giving them others useful methods.

If you want some sort of extension methods in method calls, please add a
short syntax for JSR 292 like ':' for compiling "list:sort();" as
"InvokeDynamic.sort(list);": it will be useful for many more Java code
than simple extension methods. You will have, near for free,
declaration-site extensions (with an annotation added) and IDE
completion using this annotation, use-site extensions (with some user
code for managing CallSite) but without IDE completion if there is not a
new annotation on the registered linkage method for declaring extensions
added on classes.

Thanks for some explanations on lack of relations between extension
methods and JSR 292,
Daniel.