> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2003 7:20 PM > To: Jakarta Commons Developers List > Subject: RE: cvs commit: > jakarta-commons/beanutils/src/test/org/apache/commons/beanutils > PropertyUtilsTestCase.java TestBean.java >
... > > <quote> > > By default, we use design patterns to locate properties by looking > > for methods of the form: > > public < PropertyType> get< PropertyName>(); > > public void set< PropertyName>(< PropertyType> a); > > If we discover a matching pair of "get<PropertyName>" and > > "set<PropertyName>" methods that take and return the same type, then > > we regard these methods as defining a read-write property whose name > > will be "<propertyName>". We will use the "get<PropertyName>" method > > to get the property value and the "set<PropertyName>" method to set > > the property value. The pair of methods may be located either in the > > same class or one may be in a base class and the other may be in a > > derived class. > > > > If we find only one of these methods, then we regard it as defining > > either a read-only or a writeonly property called "<propertyName>" > > > > This is the key sentence. The introspection code will find getFoo() and > isFoo() that return boolean and pick isFoo(), but they won't find > setFoo(boolean). Therefore, the JDK thinks that there is a read-only > boolean property named foo. This is where I get confused. I cannot read this sentence, in any way, as identifying that the get/is method will be selected over the set method in determining the readability or writeability (or the type) of the property. This sentence does say that if ONLY ONE of the methods (get or set) is present, then it is clear whether the property is read-only (get present/set absent) or write-only (get absent/set present). I also have no difficulty believing that the type of the property is also clear from the return type of the single get method or the argument type of the singe set method. This sentence does NOT say anything about what happens when there's a conflict between the types of get and set methods. And, as I noted in my last mail, the next section of the spec simply notes that, for boolean properties (where the type is clear), an is method preferentially serves as a replacement for the get method. Again, no mention of what happens when there is a conflict. > It would have made more sense to me for introspection to decide that > there was no property at all because of the type mismatch on the setter, > but alas that is not the way it actually works, so it's nothing > BeanUtils can really do anything about anyway (i.e. I will veto any > suggestion that BeanUtils define properties in any way different than > what the standard JDK introspection does). ... ... > I don't see anything explicit in the spec either ... all I see is what > JDKs actually do. ... Agreed 100%! Despite what I've said above, it seems clear that, particularly where there is no clear specification (as seems to be the case here), BeanUtils would be well served to follow the behaviour of standard implementations, rather than making up its own rules. However, because it's not in the spec (maybe I'm still missing this), DO all (or at least most) of the JDK's out there besides besides SUN's actually behave in this manner? Cheers, -AMT --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
