RE: [VOTE] Issue #TTWS38 - Update ValueParsers to return nullwhen appropriate

[Quinton McCombs <qm...@nequalsone.com>]

+1

> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au] 
> Sent: Sunday, January 26, 2003 3:56 AM
> To: turbine-dev
> Subject: Re: [VOTE] Issue #TTWS38 - Update ValueParsers to 
> return nullwhen appropriate
> 
> 
> On 25/01/2003 2:10 AM, "Quinton McCombs" 
> <qm...@nequalsone.com> 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:seade@backstagetech.com.au]
> >> Sent: Friday, January 24, 2003 8:44 AM
> >> To: Scott Eade
> >> Cc: turbine-dev@jakarta.apache.org
> >> 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
> >>              seade@backstagetech.com.au - 
> >> (seade@backstagetech.com.au)
> >> 
> >> 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-> unsubscribe@jakarta.apache.org>
> >> For
> >> additional commands,
> >> e-mail: <ma...@jakarta.apache.org>
> >> 
> >> 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:turbine-dev-> unsubscribe@jakarta.apache.org>
> > For 
> additional commands, 
> e-mail: 
> > <ma...@jakarta.apache.org>
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:turbine-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>