ACCEPTABLE? factory interfaces?

Reinier Zwitserloot reinier at
Sat Mar 14 09:29:35 PDT 2009

I really doubt it, and my plate is a little bit too full to write it  
up, but perhaps someone else wants to run with it.

Based on the factory interface idea Stephen linked to in an earlier  
email at

My rough sketch makes it a little easier and avoids requiring any  
changes to the JVM. Any class literal is autoboxed into an object  
assignable to the meta interface type when used in a place where the  
meta interface type is valid but the class literal's type is not. This  
autoboxing process calls a predefined library (kind of like how java's  
primitives to objects autoboxing calls Integer.valueOf and friends),  
which will return a singleton (only GCed if both the class literal is  
GCed and the proxy singleton is GCable) that has normal (non-static)  
methods, which are just proxies to the actual static methods.

The bigger issues that need to be addressed by such a proposal include  
(list is complete as far as I can tell):

  - Should interfaces be explicit in whether they are meant as a  
factory-interface or not? There's no reason for them to be  
technically, and there are certain cases where you'd want to be able  
to interchangably use a class'es static methods or an actual object's  
instance methods, but it might be confusing. My suggestion: Yes, make  
them explicit.... but how? New keyword seems almost unavoidable.

  - How do you specify that your class factory-implements something? A  
new keyword? Or a new type of interface so that the compiler knows  
when it sees this special type of interface on the 'implements' list  
that its about a factory-interface? My suggestion: Again, be explicit,  
reuse the newly created keyword.

  - How do you handle constructors? My suggestion: Make the identifier  
'constructor' have special meaning. Disallows using an actual static  
method named 'constructor', though.

A fun little exercise to show what you can do with this:

//First generics arg is automatically translated to implementing class.
public factory interface Numeric<T extends Number> {
     T zero();
     T seq(T in);

public class Integer factory implements Numeric<Integer> {
     public static Integer zero() { return 0; }
     public static Integer seq(Integer in) { return in+1; }

public class NumberUtils {
     public static <T> T one(Numeric<T> numericClass) {
         return numericClass.seq(;

public class Example {
     public static void main(String[] args) {
         assert 1 ==;
         //sugar in above line: autobox Integer class object to  
Numeric<T> wrapper

eh, still much too complicated for coin, I think.

  --Reinier Zwitserloot

On Mar 14, 2009, at 15:25, Stephen Colebourne wrote:

> Reinier Zwitserloot wrote:
>> So what proposals are still fermenting in the minds of coin
>> contributors? Inspired by the recent discussion between Joe D'Arcy  
>> and
>> Mark Mahieu that people are possibly thinking someone else will be
>> proposing it.
> * For-each loop for Maps, based on
> for (String str, Integer val : map) {
> }
> * Iteration control in For-Each loops, based on
> for (String str : list : it) {
>   it.index();
>   it.hasNext();
>   it.remove();
> }
> Abstract enums would be extremely useful, but are probably too big -
> I also thought List comprehensions might come up (not by me) -
>> - factory interfaces (an interface to describe constructors and
>> static methods). I've got a simple way to do it, but I don't think
>> its simple enough for coin.
> See static implements. And yes, its a  
> great
> idea, but too complex for Coin.
> public class Foo implements static Iterable {
>   public static Iterator iterator() {...}
> }
> Stephen

More information about the coin-dev mailing list