Issue1708944

classification
Title: overloaded setters in java not seen
Type: Severity: normal
Components: None Versions:
Milestone:
process
Status: closed Resolution: invalid
Dependencies: Superseder:
Assigned To: Nosy List: cgroves, crotwell
Priority: normal Keywords:

Created on 2007-04-27.19:13:49 by crotwell, last changed 2007-05-06.06:56:37 by cgroves.

Messages
msg1573 (view) Author: Philip Crotwell (crotwell) Date: 2007-04-27.19:13:49
public class StringBean {
   String[] pod;
   public String[] getPod() {
       return pod;
   }
   public void setPod(String[] pod) {
       this.pod = pod;
   }
   public void setPod(String pod) {
       this.pod = new String[] {pod};
   }
}

with the above class, this code fails in jython:
s = StringBean()
s.names='polebean'

with a can't convert String to String[] error:
TypeError: can't convert 'polebean' to [Ljava.lang.String;

Seems that jython should look for other "setters" that match the type of the RHS even if they take an argument of a different type from the getters return value.

Looking at the code, I think the problem steems from the fact that PyBeanProperty holds a single setter Method.

In PyType.fillInClassic(), the only methods that are searched for to put in the PyBeanProperty are ones with the correct name, ie setXYZ and with a single argument that is of the same type as the return of the getter. Any methods named correctly, setXYZ but with a different type in the argument are ignored.

In addition, if there is no getter, then the last setter to be found determines the bean params type. Probably would be better to not have a type if there are multiple setters but not a getter to specify it. Why would the last setter found be more important than the first one?

In some sense overloading setters isn't part of the real "javabean spec" but it seems a reasonible thing for java classes to do and would be nice if jython handled it.
msg1574 (view) Author: Charlie Groves (cgroves) Date: 2007-05-06.06:56:37
The problem with this is that since it isn't a part of the javabean spec there's no rule as far as pluralization of the setter name goes.  In your StringBean example, I would have named the methods getPods, setPods, and setPod so your patch wouldn't match for single assignments.  Naturally, we could extend the patch to handle 'append an s' plurals, but then when my bread management javabean has getLoaves, setLoaves and setLoaf and b.loaves = 'pumpernickel' fails I'll be confused and hungry.  

Putting a single item in a list and assigning it to an array javabean works, so I don't think this is too big of a problem.  ie
s = StringBean()
s.pods = ['polebean']

does what you'd expect it to.
History
Date User Action Args
2007-04-27 19:13:49crotwellcreate