The fact that factory methods are pure convention, rather than something
understood by the language and tool chain (e.g., should be segregated
from other static methods by Javadoc), has caused challenges for a
number of features, and so some more formal notion of "factory method"
is a reasonable thing to put on the table. This comes up, for example,
in records -- one of the unfortunate compromises (without a linguistic
notion of factories) is users get forced to choose between using records
and encapsulating the constructor.
The syntax you propose has the problem (though some might say it is a
strength) that it gives up one of the best things about factory methods:
naming. Being able to have separate names is useful both to class
authors (makes it more clear what the member does) and clients (code is
more self-descriptive.)
All that said, does this help your students in this case beyond having a
more obvious and uniform place to put the type witnesses -- new Foo<T>()
rather than Foo.<T>of() -- or is that the whole story?
On 10/6/2018 5:55 AM, Remi Forax wrote:
I've observed an interesting side effect of the introduction of var that
troubles my students,
the introduction of var make the generics method call with type arguments
needed to be mentioned more frequent.
writing
List<String> list = List.of();
foo(list); // foo takes a List of String
works out of the box but
var list = List.of();
foo(list);
will not compile because list is inferred as List<Object>
Explicitly specifying the type arguments
var list = List.<String>of();
foo(list);
works but this syntax is far from obvious for my students.
This lead me to think again about introducing a syntax for supporting static
factory method (yes, i know, it seems remote, but it's connected).
My students has no issue with specifying the type argument when calling a
constructor
var list = new ArrayList<String>();
so
why not resurrect the proposal to have a syntax to be able to declare static
factory method at language level and being able to call it with new ?
I propose to re-use 'new' when defining a static factory method
interface Fun {
static Fun new() {
return ...
}
}
and teach the compiler that new Fun() should be translated to invokestatic
Fun.new() in this case.
It is obvioulsly related to value types and the way the compiler currently
desugars constructor of value type. The desugaring of the constructor call is
exactly the same as this proposal,
what we are adding here is the fact that a developer can ask for such
translation by adding a static factory instead of being only a magic
translation from the compiler.
Rémi
