You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Russell Edens <Ru...@concur.com> on 2002/02/05 10:12:44 UTC
RE: [patch]BaseValueParser support for shorts
IMO - this should be fixed, as orginaly posted, in the BaseValueParser
instead of Torque. The method setProperties can be used with any object,
Peer objects just happen to be most frequent canidate for mapping form data
into an object. Any other object that uses a short as a property will
always fail without this change to BaseValueParser. Please let me know if
you would like a repost of the orginal patch.
Russell
> -----Original Message-----
> From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> Sent: Wednesday, January 30, 2002 7:08 PM
> To: Turbine Developers List
> Subject: Re: [patch]BaseValueParser support for shorts
>
>
> Russell Edens <Ru...@concur.com> writes:
>
> >> I take it the use of Torque is hurting your ability to
> just downcast
> >> the int?
> >
> > That right.
> >
> > If anybody uses shorts in their databases today, Torque
> will generate
> > shorts in the base objects and the BaseValueParser will fail. This
> > patch fixes this problem.
>
> Then either the patch should be committed, or Torque should
> be modified.
>
> > I still don't understand your reluctance to take a patch that adds
> > support for another native type. My case is not special or
> unique.
> > If I am using an object (my own, or out of a library) and want to
> > populate it using the BaseValueParser, it will fail if it
> has a short.
>
> You never indicated the reasoning behind need for the patch
> -- I merely asked you to explain it. Now that you've shared
> that information with the rest of us, it makes more sense.
> Not having short available doesn't hurt, since you can use
> the int API and downcast (but the issue remains with Torque
> regardless).
>
> --
> 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>
Re: [patch]BaseValueParser support for shorts
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Please resend the patch as a unidiff and I'll commit it.
Russell Edens <Ru...@concur.com> writes:
> IMO - this should be fixed, as orginaly posted, in the BaseValueParser
> instead of Torque. The method setProperties can be used with any object,
> Peer objects just happen to be most frequent canidate for mapping form data
> into an object. Any other object that uses a short as a property will
> always fail without this change to BaseValueParser. Please let me know if
> you would like a repost of the orginal patch.
>
> Russell
>
>> -----Original Message-----
>> From: Daniel Rall [mailto:dlr@finemaltcoding.com]
>> Sent: Wednesday, January 30, 2002 7:08 PM
>> To: Turbine Developers List
>> Subject: Re: [patch]BaseValueParser support for shorts
>>
>>
>> Russell Edens <Ru...@concur.com> writes:
>>
>> >> I take it the use of Torque is hurting your ability to
>> just downcast
>> >> the int?
>> >
>> > That right.
>> >
>> > If anybody uses shorts in their databases today, Torque
>> will generate
>> > shorts in the base objects and the BaseValueParser will fail. This
>> > patch fixes this problem.
>>
>> Then either the patch should be committed, or Torque should
>> be modified.
>>
>> > I still don't understand your reluctance to take a patch that adds
>> > support for another native type. My case is not special or
>> unique.
>> > If I am using an object (my own, or out of a library) and want to
>> > populate it using the BaseValueParser, it will fail if it
>> has a short.
>>
>> You never indicated the reasoning behind need for the patch
>> -- I merely asked you to explain it. Now that you've shared
>> that information with the rest of us, it makes more sense.
>> Not having short available doesn't hurt, since you can use
>> the int API and downcast (but the issue remains with Torque
>> regardless).
>>
>> --
>> 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>