Re: Rationale for SDO DataType Conversions
Thanks. I take the point about convenience. I think what was puzzling me was that in a number of cases there isn't any convenience. No one in the real world is ever going to do getByte on a value that was stored as a Double. But having conversions like that in the spec just clutters both the spec and the implementation. I'm not objecting to all conversions. As I said in the base note, some make perfect sense. I was just puzzled by the fact that some of the ones that SDO offers don't really deliver any value (that I can see) to the user and yet they add burden for the developers. I'll ask this in the spec mailing list as Frank suggests. Geoff. On 20/07/06, Yang ZHONG [EMAIL PROTECTED] wrote: Geoff, while providing convenience as Frank explains, the spec doesn't prevent users from converting themselves. e.g. a user can always converts from double to byte then calls setByte. Are you proposing to always force users to convert and setXxx fails with mismatched Type? On 7/20/06, Frank Budinsky [EMAIL PROTECTED] wrote: Geoff, I don't really know the answer, but my guess is that it's simply a matter of trying to provide as much convenience as possible. I think you should ask this question on the SDO spec collaboration mailing list. Frank. Geoffrey Winn [EMAIL PROTECTED] wrote on 07/20/2006 08:36:09 AM: This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff. -- Yang ZHONG
Rationale for SDO DataType Conversions
This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff.
Re: Rationale for SDO DataType Conversions
Geoff, I don't really know the answer, but my guess is that it's simply a matter of trying to provide as much convenience as possible. I think you should ask this question on the SDO spec collaboration mailing list. Frank. Geoffrey Winn [EMAIL PROTECTED] wrote on 07/20/2006 08:36:09 AM: This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for SDO DataType Conversions
Geoff, while providing convenience as Frank explains, the spec doesn't prevent users from converting themselves. e.g. a user can always converts from double to byte then calls setByte. Are you proposing to always force users to convert and setXxx fails with mismatched Type? On 7/20/06, Frank Budinsky [EMAIL PROTECTED] wrote: Geoff, I don't really know the answer, but my guess is that it's simply a matter of trying to provide as much convenience as possible. I think you should ask this question on the SDO spec collaboration mailing list. Frank. Geoffrey Winn [EMAIL PROTECTED] wrote on 07/20/2006 08:36:09 AM: This may be the wrong forum for this question (in which case maybe someone can suggest the right one) however, I'm a bit puzzled by some of the built in datatype conversions that SDO performs. Some conversions are obvious, such as Byte to any of the wider integer forms. However others are more questionable. For example, referring to page 146 of V2.01 of the Java Spec, it seems to be possible to convert a Double to Byte. I can see that occasionally that will work, and occasionally it will work with a modest amount of rounding, but in most cases the result is just noise. Long to Byte is another one that will fail a lot more often than it succeeds. The obvious reply to this is that it is up to the user to make sure that these conversions are invoked only when they make sense - but if the user has to take that responsibility, then they might as well do the conversion themselves. I just wondered what the reasoning was behind including such a wide range of conversions. Regards, Geoff. -- Yang ZHONG
