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

Ron Thomas the.ront at gmail.com
Sun Mar 29 22:15:19 PDT 2009

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(METHOD_SIG)

METHOD_SIG := METHOD_NAME([[PARAM_TYPE,]* PARAM_TYPE]) : [RETURN_TYPE] [throws [[EXCEPTION,] EXCEPTION]* METHOD_NAME := java legal method name PARAM_TYPE := java legal parameter type RETURN_TYPE := 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