Proposal: Generic Specification by Method

[Ulf Zibis]

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<T> 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<T> 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<T> resources) {
>     for (T t : resources) {
>         t.close();
>     }
> }
>
> Would effectively become:
> <T extends Object>
> void closeAllResources(List<T> 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:
>
>
>