ACCEPTABLE? factory interfaces?
Reinier Zwitserloot
reinier at zwitserloot.com
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 http://www.jroller.com/jadda/entry/meta_interfaces_revisited
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(numericClass.zero());
}
}
public class Example {
public static void main(String[] args) {
assert 1 == NumberUtils.one(Integer.class);
//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
> http://www.jroller.com/scolebourne/entry/java_7_for_each_loops
>
> for (String str, Integer val : map) {
> }
>
> * Iteration control in For-Each loops, based on
> http://www.jroller.com/scolebourne/entry/java_7_for_each_loop
>
> for (String str : list : it) {
> it.index();
> it.hasNext();
> it.remove();
> }
>
>
> Abstract enums would be extremely useful, but are probably too big -
> http://freddy33.blogspot.com/search/label/abstract%20enum
>
> I also thought List comprehensions might come up (not by me) -
> http://docs.google.com/View?docid=d4tx2hw_46fkz8x6gt
>
>
>> - 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 https://kijaro.dev.java.net/ 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