> class X {
> public void setYoo(String s) {}
> public void setYoo(int i) {}
> }
>
> > javac Test
> > java Test
> Name: yoo, read: null, write: public void X.setYoo(java.lang.String)
> Name: class, read: public final native java.lang.Class
> java.lang.Object.getClass(), write: null
>
> Oops, setYoo(int) is gone. Scarry no? (This is on JDK 1.3.1.)
>
> I think it is best to simply shy away from homonym setter methods. We
> should not try to compensate for this JavaBeans introspection
> behavior. You
> might have a different analysis of the situation. So I'm all ears.
Well, you can argue, and maybe your are, that the int setter "obscured" the
String setter in the first case. Which one do we want to prefer?
We can write the generic method lookup code to prefer any other argument
type (ie int) over a string, given that it can convert the string to that
type. If it cannot convert to that type, then fallback to using the string
version. That is similar to what the javadoc in PropertySetter says right
now, I think.
Whether one wants it to work this way or not is a different matter. I don't
see any reason to not provide some flexibility in this regard.
I have already updated the MatchFilterBase class to only support a string
version. It is kind of goofy that one cannot use the Filter constants from
code (as one will use String values from a configuration file), but it is
not horrific.
-Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
