Proposal: Generic Specification by Method (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Mon Mar 30 11:39:00 PDT 2009

I more would prefer java like syntax: having(void close())

-Ulf

Am 30.03.2009 07:15, Ron Thomas schrieb:

I would like to propose an extension to generics that would allow a generic type to be specified by methods in addition to the current inheritance/implementations.

Generics by Method AUTHOR(S): Ron Thomas OVERVIEW FEATURE SUMMARY: Generics by Method allows for the use of Generics when using a common interface or super class is not an option. MAJOR ADVANTAGE: This would allow the use of generics based off of methods instead of off of classes/interfaces. MAJOR BENEFIT: Generics by Method will allow working with different classes with similar methods easier and more concise. Instead of relying on instanceof checks and class wrappers a generic type would suffice. While using Generics by Interface or super class is preferred, it is not always an option when dealing with 3rd party APIs. MAJOR DISADVANTAGE: Reflection will be used in order to achieve this goal, and the corresponding performance hit will be incurred. ALTERNATIVES: Use wrappers and class composition and use generics as-is. EXAMPLES SIMPLE EXAMPLE: The following method calls the close method on a list of resources. Unfortunately using the Closeable interface is no an option because one of the resources is supplied by a 3rd party resource does not implement the interface. public <T having(close() : void)> void closeAllResources(List resources) { for (T t : resources) { t.close(); } } ADVANCED EXAMPLE: Show advanced usage(s) of the feature. The following example requires two methods, one of which throws an exception. public <T having(close() : void) having(open(String, int) throws_ _ResourceException : int)> boolean checkResources(List resources, String host, int port) throws ResourceException { for (T t : resources) { int status = t.open(host, port); if (status < 0) {_ _return false;_ _}_ _t.close();_ _}_ _return true;_ _}_ _DETAILS_ _SPECIFICATION:_ _A having generic specification shall be added in the form:_ _having(METHODSIG)_ _METHODSIG := METHODNAME([[PARAMTYPE,]* PARAMTYPE]*) :_ _[RETURNTYPE] [throws [[EXCEPTION,]* EXCEPTION]*_ _METHODNAME := java legal method name_ _PARAMTYPE := java legal parameter type_ _RETURNTYPE := java legal return type_ _EXCEPTION := java level exception_ _The following generic expressions become legal:_ _Simple specification with no parameters._ _<T having(method() : void)> matches classes with: void method() Simple specifiation with parameters. <T having(method(int,String) : int)> matches classes with: int method(int, String) Constructor specification <T having(new(int, String) : int)> matches classes with constructor that have an int and String parameter Specification with exception <T having(method(int, String) throws AException : int)> matches classes with : int method(int, String) throws AException OR int method(int, String)

COMPILATION: The compiler would use reflection to handle calling of the generic methods themselves. For example: public <T having(close() : void)> void closeAllResources(List resources) { for (T t : resources) { t.close(); } } Would effectively become: void closeAllResources(List resources) { for (T t : resources) { try { t.getClass().getMethod("close").invoke(t); } catch (IllegalAccessException ex) { throw new RuntimeException("Method close not found"); } catch (InvocationTargetException ex) { throw new RuntimeException("Method close not found"); } catch (NoSuchMethodException ex) { throw new RuntimeException("Method close not found"); } } } The compiler would also check all uses of this feature, and generate a compiler error if any usage does not match the criteria given. TESTING: The feature can be tested by compiling and running programs that exercise the feature. LIBRARY SUPPORT: No. REFLECTIVE APIS: No. The use of this feature is compile time only. OTHER CHANGES: No. MIGRATION: No. This is a new feature and no existing code should be affected. COMPATIBILITY BREAKING CHANGES: No. EXISTING PROGRAMS: This is an addition to generics, and this change would be transparent to them. REFERENCES EXISTING BUGS:

More information about the coin-dev mailing list