Ceki G�lc� wrote:
>
> class X {
> public void setYoo(int i) {}
> public void setYoo(String s) {}
> }
>
> If you compile and run Test, you get:
>
> > javac Test.java
> > java Test
> Name: yoo, read: null, write: public void X.setYoo(int)
> Name: class, read: public final native java.lang.Class
> java.lang.Object.getClass(), write: null
>
> Now, if you change the order of declaration of setYoo(int) and
> setYoo(String), as in:
>
> 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.
>
In your example the introspector does not know which type to prefer
and so should not return either for the reasons that you have
illustrated.
However. as method signatures have to differ by more than return code
you
can only have one getter for "yoo". The introspector could use the
return
type of the getter as the type for the property and then can pick the
best
setter for that type.
e.g.
If you added the following method then the setYoo(String) method would
be picked by the introspector.
public String getYoo() {return "";}
If however you added the following method then the setYoo(int) method
would be picked by the introspector.
public int getYoo() {return 0;}
--
This message may contain confidential information and will be protected
by copyright. If this email isn't for you then we'd be grateful if you
could notify Volantis by return and delete it. You should not copy,
disclose or distribute any of its contents.
Any reply may be read by the recipient to whom you send it and others
within Volantis Systems Ltd.
Although we aim to use efficient virus checking procedures we accept no
liability for viruses and recipients should use their own virus checking
procedures.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
