You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2003/01/26 10:56:01 UTC
Re: [VOTE] Issue #TTWS38 - Update ValueParsers to return null
when 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: <ma...@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>
RE: [VOTE] Issue #TTWS38 - Update ValueParsers to return nullwhen appropriate
Posted by 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>