On Mon, Apr 7, 2008 at 2:33 PM, Paul Cowan <[EMAIL PROTECTED]> wrote: > Hi James, > > > James Carman wrote: > > > public Object createDelegatorProxy( ObjectProvider delegateProvider, > > Class... proxyClasses ); > > > > However, I also want to add in a nice helper method like this: > > > > public <T> T createDelegatorProxy( ObjectProvider<T> delegateProvider, > > Class<T> proxyClass ); > > > > I'm not overly familiar with proxy, but will this work? > > public <T> T createDelegatorProxy(ObjectProvider<T> delegateProvider, > Class<T> primaryProxyClass, Class... otherProxyClasses); > > That combines the generic version and the non-generic version into one > method, with generics for people who pass one Class and beyond that no > generics are used. It's not QUITE the same as your two methods... firstly > you have to commit to passing an ObjectProvider of the same <T> type as the > first class (which may make for a confusing API? not sure) and it also means > you HAVE to pass at least one proxy class, you can't just call > createDelegatorProxy(delegateProvider); > which your varargs methods let you do. I don't know if that's a good thing > or a bad thing in this case?
Well, I think it might be confusing that you're potentially passing in additional classes, but only really concerned with the "primary". I'm glad folks are thinking about it, though! :) The single-class version is a very nice addition, IMHO, since that should probably cover 89.27% of the use cases (did you know that 90% of statistics are made up on the spot?). If the single version and the varargs version can live together peacefully, it's a big plus. So far, in rewriting it, the test cases don't seem to be breaking when I started using the single class version instead where applicable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
