At 16:07 12.06.2002 -0700, you wrote:
> > 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.
Log4j does not take any initiative on this matter. It relies
completely on the getBeanInfo() of java.beans.Introspector class to
find properties which apparently gives precedence to order of
declaration of methods in a class as Test.java illustrates.
>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.
It may be too much work for what it's worth. One no brainer solution
is to change the name of the methods as in:
setMatchReturnValue(String)
setMatchReturnValueAsInt(int)
int getMatchReturnValueAsInt()
setNoMatchReturnValue(String)
setNoMatchReturnValueAsInt(int)
int getNoMatchReturnValueAsInt()
Note that there are no String getters. Also note that the getter
methods have an "AsInt" suffix removing them may obscure the String
setters.
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.
I see that in MatchFilterBase there are two methods with the name
setMatchReturnValue of which the String version is declared
first. This explains why your test cases work...
I agree that the String getter getMatchReturnValue() and
getNoMatchReturnValue() are goofy.
Thanks for the new test cases by the way.
>-Mark
--
Ceki
SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
