On 25/01/2003 2:10 AM, "Quinton McCombs" <[EMAIL PROTECTED]> wrote:
> This issue contains a patch that will change the behavior of > DefaultValueParser. All of the methods wheich would return an object > type would return NULL is the value is not prsent. Currently methods > such as getInteger(key) will return an Integer with a value of 0. > Methods such as getInt(key) would remain unchanged. > > Since this will change the current behavior in a way that could break > existing code, I wanted to get everyone else's opinion on it before > appling the patch. It seems to me that the current behaviour is inconsistent and that these methods are slowly being converted over to returning null as people start using them. A year or more ago the getNumberKey() method was modified to work this way and the discussion of getInteger() a few days back netted no negative responses. I personally don't mind about the getBool() and getBigDecimal() methods, but updated them for consistency. My feeling is that the primary reason people are using objects over primitives is to allow for null, so the existing behaviour for getInteger() and getBool() just seems plain wrong. This would leave getBigDecimal() out there on its own as the only one of these methods that conjures up a default value when the key is not found. On top of this there are always the versions of the methods that provide for specified default values - IMO it is way more appropriate for the API user to determine their own default values than for us to impose them. > > One other thing, should this also be applied to the 2.2.1 verion as well > as 2.3? The getIntegr() change is prompted by the more prevalent use of getInteger() when javaType="object" is used in a torque schema under turbine 2.2/torque 3.0. I would therefore argue that this change should go into 2.2.1. The getBool() and getBigInteger() changes can hold off to 2.3. I think Quinton that it may just be you and I discussing this one, so let me know if you agree and I will commit the change as discussed above. Cheers, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au .Mac Chat/AIM: seade at mac dot com > >> -----Original Message----- >> From: Scott Eade [mailto:[EMAIL PROTECTED]] >> Sent: Friday, January 24, 2003 8:44 AM >> To: Scott Eade >> Cc: [EMAIL PROTECTED] >> Subject: [SOURCE] Issue #TTWS38 - Update ValueParsers to >> return null when appropriate >> >> >> You can view the issue detail at the following URL: >> <http://scarab.werken.com/scarab/issues/id/TTWS38> >> >> Type : Patch >> Issue Id : TTWS38 >> Reported by: Scott Eade >> [EMAIL PROTECTED] - ([EMAIL PROTECTED]) >> >> Details: >> >> Platform: All >> Operating system: windows 2000 >> Summary: Update ValueParsers to return null when appropriate >> Description: For some Object return types >> ValueParser/BaseValueParser currently return Object >> equivalents of uninitialised primitive values when the keys >> are not included in the underlying HashTable. To be more >> useful and to be consistent with the other Object types, the >> Bool, BigDecimal and Integer return types should return null >> when the key is not found. >> Status: New >> Priority: High >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:turbine-dev-> [EMAIL PROTECTED]> >> For >> additional commands, >> e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
