Issue 1673: Custom marshalling support for IDL fixed type (obv-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The custom marshalling streams CDRInputStream and CDROutputStream don"t support the IDL fixed type. I propose adding the following type definition and methods: typedef sequence<fixed> FixedSeq; abstract value CDROutputStream { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }; abstract value CDRInputStream { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }; Resolution: Revised Text: Actions taken: July 13, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Mon, 13 Jul 1998 15:35:25 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: obv-rtf@omg.org Cc: issues@omg.org Subject: Custom marshalling support for IDL fixed type The custom marshalling streams CDRInputStream and CDROutputStream don't support the IDL fixed type. I propose adding the following type definition and methods: typedef sequence FixedSeq; abstract value CDROutputStream { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }; abstract value CDRInputStream { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }; Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Mon, 13 Jul 1998 14:02:43 -0400 From: mmihic Reply-To: mmihic Organization: IONA Technologies, Inc. Priority: Normal To: nash@hursley.ibm.com, Jonathan Biggar , obv-rtf@omg.org, orb_revision@omg.org Subject: Re[2]: Custom marshalling support for IDL fixed type References: <35AA345F.BACFB8E9@floorboard.com> > > typedef sequence FixedSeq; > > abstract value CDROutputStream { > ... > void write_fixed (in any value); > void write_fixed_array (in FixedSeq seq, > in unsigned long offset, > in unsigned long length); > }; > abstract value CDRInputStream { > ... > any read_fixed (); > void read_fixed_array (inout FixedSeq seq, > in unsigned long offset, > in unsigned long length); > }; If they want to send a fixed inside an any, they should use the read/write_any methods. We should not be introducing new methods which claim to be type-specific, but are neither type-specific nor type-safe. Regards, Matt Return-Path: Date: Mon, 13 Jul 1998 19:15:03 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Jonathan Biggar Cc: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <35AA1B2D.94CB31D1@mailserver.hursley.ibm.com> <35AA345F.BACFB8E9@floorboard.com> Jonathan (and Steve), Thanks for the IDL lesson :-) In that case, I withdraw my proposal, since OBV custom marshalling already has operations for writing and reading the any type. The reason I was confused by this is that support for fixed was recently added to the IDL/Java mapping, with no reference to fixed. It just says that fixed is mapped to java.math.BigDecimal, and there are new stream operations for writing and reading it. If anyone is reading who's familiar with this, does that mean that all 495 possible combinations of d and s are mapped to Java in the same way? Simon Jonathan Biggar wrote: > > Simon Nash wrote: > > > > The custom marshalling streams CDRInputStream and CDROutputStream > > don't support the IDL fixed type. I propose adding the following > > type definition and methods: > > > > typedef sequence FixedSeq; > > > > abstract value CDROutputStream { > > ... > > void write_fixed (in fixed value); > > void write_fixed_array (in FixedSeq seq, > > in unsigned long offset, > > in unsigned long length); > > }; > > > > abstract value CDRInputStream { > > ... > > fixed read_fixed (); > > void read_fixed_array (inout FixedSeq seq, > > in unsigned long offset, > > in unsigned long length); > > }; > > I'm afraid that doesn't work. There is no single "fixed" type, but > a > whole family of "fixed" template types (495 of them, if I > counted > right). As far as I can tell, the only way to make this work right > is > to embed the fixed type in an any like this: > > typedef sequence FixedSeq; > > abstract value CDROutputStream { > ... > void write_fixed (in any value); > void write_fixed_array (in FixedSeq seq, > in unsigned long offset, > in unsigned long length); > }; > > abstract value CDRInputStream { > ... > any read_fixed (); > void read_fixed_array (inout FixedSeq seq, > in unsigned long offset, > in unsigned long length); > }; > > Yes, it's painful and annoying, but it's the only way you can write > this > in IDL. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 11:41:43 -0700 From: Jonathan Biggar To: nash@hursley.ibm.com CC: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <35AA1B2D.94CB31D1@mailserver.hursley.ibm.com> <35AA345F.BACFB8E9@floorboard.com> <35AA4EA7.5D727FCA@mailserver.hursley.ibm.com> Simon Nash wrote: > > Jonathan (and Steve), > Thanks for the IDL lesson :-) In that case, I withdraw my proposal, > since OBV custom marshalling already has operations for writing and > reading the any type. No, you still need the proposal, since using read/write_any will not result in the correct information inserted into the CDR stream. To clarify: write_fixed(in any val); would encode into the CDR stream the value of the fixed point type contained in the Any, but: write_any(in any val); would encode into the CDR stream a TypeCode, followed by the value in the any, which is a different result. > The reason I was confused by this is that support for fixed was > recently added to the IDL/Java mapping, with no reference to > fixed. It just says that fixed is mapped to > java.math.BigDecimal, > and there are new stream operations for writing and reading it. > If anyone is reading who's familiar with this, does that mean that > all > 495 possible combinations of d and s are mapped to Java in the > same way? Yes, this is a reasonable mapping for Java (and for other languages with "generic" fixed point support, like Smalltalk). This means, of course, that you loose any specification of the digits and scale while using the fixed point value in Java, but your IDL compiler generated stubs should raise the MARSHAL exception if someone tries to transmit a fixed-point value that doesn't fit in the digits and scale of a fixed-point argument to an IDL operation, which is the same way that bounded strings are handled in many languages. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 13 Jul 1998 15:41:14 -0400 From: mmihic Reply-To: mmihic Organization: IONA Technologies, Inc. Priority: Normal To: nash@hursley.ibm.com, Jonathan Biggar , obv-rtf@omg.org, orb_revision@omg.org Subject: Re[2]: Custom marshalling support for IDL fixed type References: <35AA54E7.CBE8DBBA@floorboard.com> > No, you still need the proposal, since using read/write_any will not > result in the correct information inserted into the CDR stream. To > clarify: > write_fixed(in any val); > would encode into the CDR stream the value of the fixed point type > contained in the Any, but: > write_any(in any val); > would encode into the CDR stream a TypeCode, followed by the value in > the any, which is a different result. I continue to disagree with this. I understand the desire, but I think the fact that you cannot express generic fixed in IDL is indicative of a larger problem (see Michi Henning's comments on DynFixed in the Portability Revision Issues List). Getting around the issue in this manner is IMO not the best way to proceed -- it will result in lots of little inconsistencies. For example, the current proposal (use of any) is inconsistent with the existing DynFixed interface (which provides access to generic fixed through the use of octet sequences). For now, I am of the opinion that we should not add fixed to the custom marshalling interface until this "generic fixed" issue is addressed. Regards, Matt Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 13:05:28 -0700 From: Jonathan Biggar To: mmihic CC: nash@hursley.ibm.com, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <35AA54E7.CBE8DBBA@floorboard.com> <11653.980713@iona.com> mmihic wrote: > > > No, you still need the proposal, since using read/write_any will > not > > result in the correct information inserted into the CDR stream. > To > > clarify: > > > write_fixed(in any val); > > > would encode into the CDR stream the value of the fixed point type > > contained in the Any, but: > > > write_any(in any val); > > > would encode into the CDR stream a TypeCode, followed by the value > in > > the any, which is a different result. > > I continue to disagree with this. I understand the desire, but I > think > the fact that you cannot express generic fixed in IDL is indicative > of > a larger problem (see Michi Henning's comments on DynFixed in the > Portability Revision Issues List). Getting around the issue in this > manner is IMO not the best way to proceed -- it will result in lots > of > little inconsistencies. For example, the current proposal (use of > any) is inconsistent with the existing DynFixed interface (which > provides access to generic fixed through the use of octet > sequences). The proposal, as I modified it, provides the simplest way for a programmer, given a fixed to get it into a CDR stream. Yes, it's a little kludgy; yes it's not a compile-time type-safe interface, but it is the best that can be done given the current definition of the IDL fixed point type. Your comparison to DynFixed is a red herring. DynFixed is for programs without compile time support for a specific fixed (which is possible for the Ada binding) to construct and access the value of any arbitrary fixed point type. The read/write_fixed() operations on CDR streams, however, is for a programmer who already has a fixed-point type to get it into a CDR stream. There is no requirement that these two operations be harmonized to look pretty, because they do two entirely different things. > For now, I am of the opinion that we should not add fixed to the > custom marshalling interface until this "generic fixed" issue is > addressed. There is currently a proposal to the ORB core RTF (by yours truely) to resolve the fixed issues for the core as we email. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 13 Jul 1998 18:20:35 -0400 From: mmihic Reply-To: mmihic Organization: IONA Technologies, Inc. Priority: Normal To: Jonathan Biggar , obv-rtf@omg.org, orb_revision@omg.org CC: vinoski@iona.com Subject: Re[2]: Custom marshalling support for IDL fixed type References: <35AA6888.BA8D195E@floorboard.com> > Your comparison to DynFixed is a red herring. DynFixed is for programs > without compile time support for a specific fixed (which is > possible for the Ada binding) to construct and access the value of any > arbitrary fixed point type. The read/write_fixed() operations on CDR > streams, however, is for a programmer who already has a fixed-point type > to get it into a CDR stream. > There is no requirement that these two operations be harmonized to look > pretty, because they do two entirely different things. You are correct that one issue with DynFixed::get_value is the inability to construct and access an arbitrary fixed point type. However, this is not the issue with DynFixed::set_value. The application has already constructed the specific fixed type they want to insert; the problem is that DynFixed::set_value cannot accept this fixed type directly because it must work with arbitrary fixed point types, and there is no way to express an arbitrary fixed point type in IDL. I spoke with Steve Vinoski and he confirmed that this is the reason he designed DynFixed::set_value to take an OctetSeq. It is *exactly* the same problem as faced by the custom marshalling streams. I continue to oppose introducing the read_fixed/write_fixed methods as described to custom marshalling. They do not address the base problem of representing arbitrary fixed types in IDL, they are inconsistent with previous work-arounds for the same problem, they break the previous paradigm of making the type-specific read/write methods type-safe at compile-time, and they violate the concept of any by using it as an opaque data store rather than as a self-describing type. IMO support for fixed types in custom marshalling should wait until the base problem is addressed; failing this, the work-around for custom marshalling should be the same as the work-around used in other parts of the spec. Regards, Matt ------------------ Matthew A. Mihic IONA Technologies, Inc. Phone: +1-617-949-4302 EMail: mmihic@iona.com Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 09:24:30 +1000 (EST) From: Michi Henning To: mmihic cc: Jonathan Biggar , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Re[2]: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998, mmihic wrote: > You are correct that one issue with DynFixed::get_value is the > inability to construct and access an arbitrary fixed point type. > However, this is not the issue with DynFixed::set_value. The > application has already constructed the specific fixed type they > want > to insert; the problem is that DynFixed::set_value cannot accept > this > fixed type directly because it must work with arbitrary fixed point > types, and there is no way to express an arbitrary fixed point type > in > IDL. I spoke with Steve Vinoski and he confirmed that this is the > reason he designed DynFixed::set_value to take an OctetSeq. It is > *exactly* the same problem as faced by the custom marshalling > streams. You actually can get a fixed-point value into a DynAny, but in a roundabout way. Put the fixed-point value into an Any, call ORB::create_dyn_any(), and then narrow the result to DynFixed. Not too nice though... The real problem is that conversion in the opposite direction is hard. How do I turn a DynFixed back into a real C++ fixed-point value? There is no way to do this other than to parse the octet sequence. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA0033C10BA138A5 Date: Mon, 13 Jul 1998 16:39:17 PDT Subject: Re: Re[2]: Custom marshalling support for IDL fixed type To: mmihic@iona.COM cc: Mike_Spreitzer.PARC@xerox.com, jon@floorboard.COM, obv-rtf@omg.org, orb_revision@omg.org So what would be wrong with adding a generic fixed-point type to IDL? Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 09:59:40 +1000 (EST) From: Michi Henning To: Mike_Spreitzer.PARC@xerox.com cc: mmihic@iona.COM, jon@floorboard.COM, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Re[2]: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998 Mike_Spreitzer.PARC@xerox.com wrote: > So what would be wrong with adding a generic fixed-point type to IDL? Nothing as such. Unfortunately, we would have to change the CDR for fixed-point types as well, because currently, I cannot unmarshal a fixed-point value without knowing the number of digits and its scale in advance. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA0033C10BA738A5 Date: Mon, 13 Jul 1998 17:15:03 PDT Subject: Re: Re[2]: Custom marshalling support for IDL fixed type To: michi@dstc.edu.AU cc: Mike_Spreitzer.PARC@xerox.com, mmihic@iona.COM, jon@floorboard.COM, obv-rtf@omg.org, orb_revision@omg.org We'd have to change the CDR for *generic* fixed-point types. Which, of course, wouldn't actually be a change, since they don't exist yet. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 10:21:19 +1000 (EST) From: Michi Henning To: Mike_Spreitzer.PARC@xerox.com cc: mmihic@iona.COM, jon@floorboard.COM, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Re[2]: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998 Mike_Spreitzer.PARC@xerox.com wrote: > We'd have to change the CDR for *generic* fixed-point types. Yep. Sorry, that's what I meant, but I didn't express it clearly. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Jeffrey Mischkinsky Subject: Re: Re[2]: Custom marshalling support for IDL fixed type To: michi@dstc.edu.au (Michi Henning) Date: Mon, 13 Jul 1998 18:29:45 -0700 (PDT) Cc: Mike_Spreitzer.PARC@xerox.com, mmihic@iona.COM, jon@floorboard.COM, obv-rtf@omg.org, orb_revision@omg.org 'Michi Henning' writes: > > On Mon, 13 Jul 1998 Mike_Spreitzer.PARC@xerox.com wrote: > > > We'd have to change the CDR for *generic* fixed-point types. > > Yep. Sorry, that's what I meant, but I didn't express it clearly. for what it's worth - (US$ 0.015), i tend to agree with the argument, that until fixed point gets fixed in general, we ought not to compound the problem with more kludges, etc. It is unfortunate, to the say the least, that it ever got in in its present state, but lets not make it worse. In the meantime, there is always the workaround, which is not all that outlandish considering that we already are talking about custom marshaling, to write it out as seq octet. Until we actually fix the problem in general, i'm not sure its worth spending more time on this parrticular aspect. jeff > > Cheers, > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA > http://www.dstc.edu.au/BDU/staff/michi-henning.html > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: From: Jeffrey Mischkinsky Subject: Re: Custom marshalling support for IDL fixed type To: nash@hursley.ibm.com Date: Mon, 13 Jul 1998 18:32:39 -0700 (PDT) Cc: jon@floorboard.com, obv-rtf@omg.org, orb_revision@omg.org 'Simon Nash' writes: > > Jonathan (and Steve), > Thanks for the IDL lesson :-) In that case, I withdraw my proposal, > since OBV custom marshalling already has operations for writing and > reading the any type. and next i'll find and read ALL the email on a subject before > responding to a withdrawn proposal. oops :-) jeff > > The reason I was confused by this is that support for fixed was > recently added to the IDL/Java mapping, with no reference to > fixed. It just says that fixed is mapped to > java.math.BigDecimal, > and there are new stream operations for writing and reading it. > If anyone is reading who's familiar with this, does that mean that > all > 495 possible combinations of d and s are mapped to Java in the > same way? > > Simon > > Jonathan Biggar wrote: > > > > Simon Nash wrote: > > > > > > The custom marshalling streams CDRInputStream and > CDROutputStream > > > don't support the IDL fixed type. I propose adding the > following > > > type definition and methods: > > > > > > typedef sequence FixedSeq; > > > > > > abstract value CDROutputStream { > > > ... > > > void write_fixed (in fixed value); > > > void write_fixed_array (in FixedSeq seq, > > > in unsigned long offset, > > > in unsigned long length); > > > }; > > > > > > abstract value CDRInputStream { > > > ... > > > fixed read_fixed (); > > > void read_fixed_array (inout FixedSeq seq, > > > in unsigned long offset, > > > in unsigned long length); > > > }; > > > > I'm afraid that doesn't work. There is no single "fixed" type, > but a > > whole family of "fixed" template types (495 of them, if I > counted > > right). As far as I can tell, the only way to make this work > right is > > to embed the fixed type in an any like this: > > > > typedef sequence FixedSeq; > > > > abstract value CDROutputStream { > > ... > > void write_fixed (in any value); > > void write_fixed_array (in FixedSeq seq, > > in unsigned long offset, > > in unsigned long length); > > }; > > > > abstract value CDRInputStream { > > ... > > any read_fixed (); > > void read_fixed_array (inout FixedSeq seq, > > in unsigned long offset, > > in unsigned long length); > > }; > > > > Yes, it's painful and annoying, but it's the only way you can > write this > > in IDL. > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > -- > Simon C Nash, IBM Java Technology Centre, Hursley, UK > MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 > Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 20:14:29 -0700 From: Jonathan Biggar To: mmihic CC: obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type References: <35AA6888.BA8D195E@floorboard.com> <4764.980713@iona.com> mmihic wrote: > > > Your comparison to DynFixed is a red herring. DynFixed is for > programs > > without compile time support for a specific fixed (which is > > possible for the Ada binding) to construct and access the value of > any > > arbitrary fixed point type. The read/write_fixed() operations on > CDR > > streams, however, is for a programmer who already has a > fixed-point type > > to get it into a CDR stream. > > > There is no requirement that these two operations be harmonized to > look > > pretty, because they do two entirely different things. > > You are correct that one issue with DynFixed::get_value is the > inability to construct and access an arbitrary fixed point type. > However, this is not the issue with DynFixed::set_value. The > application has already constructed the specific fixed type they > want > to insert; the problem is that DynFixed::set_value cannot accept > this > fixed type directly because it must work with arbitrary fixed point > types, and there is no way to express an arbitrary fixed point type > in > IDL. I spoke with Steve Vinoski and he confirmed that this is the > reason he designed DynFixed::set_value to take an OctetSeq. It is > *exactly* the same problem as faced by the custom marshalling > streams. > > I continue to oppose introducing the read_fixed/write_fixed methods > as > described to custom marshalling. They do not address the base > problem > of representing arbitrary fixed types in IDL, they are inconsistent > with previous work-arounds for the same problem, they break the > previous paradigm of making the type-specific read/write methods > type-safe at compile-time, and they violate the concept of any by > using it as an opaque data store rather than as a self-describing > type. IMO support for fixed types in custom marshalling should wait > until the base problem is addressed; failing this, the work-around > for > custom marshalling should be the same as the work-around used in > other > parts of the spec. Let's try a separate the two parts of the argument, since they seem so tangled up right now. The first question is should we throw away the current IDL fixed format and replace it with a generic fixed point type. The second argument is, assuming we don't replace fixed is how to provide generic mechanisms to support DynFixed and CDR streams. Let me consider the second argument first, just to get it out of the way. Since we are assuming here that fixed is here to stay (again, for the sake of the argument), the question is whether the current DynFixed get/set_value and the proposed read/write_fixed solve the problem at hand. For DynFixed, I could see a second pair of operations: string get_string_value(); void set_string_value raises(InvalidValue); that would allow the application to get and set the value as a string. This would provide additional flexibility to the application. I could also see each language mapping providing a helper function (if necessary) to convert the string or the OctetSeq to and from a generic fixed point value, for languages that provide a fixed point value. For read/write_fixed, using any seems to be the exactly correct solution given the constraints above. When you consider the intended use of CDR streams, which is to support marshalling OBV values, this doesn't seem to add overly much overhead. Now, back to the first question, should we scrap fixed and replace it with a generic fixed. I see several arguments against this: 1. The digits and scale are useful to provide an explicit contract in the IDL source of the range of values permitted. 2. The Ada language, in particular, does not support a generic fixed point type, only a type with a fixed digits and scale. 3. A generic fixed point value is going to be larger than one limited to a specific digits and scale. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 14:46:46 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998, Jonathan Biggar wrote: > Let's try a separate the two parts of the argument, since they seem so > tangled up right now. The first question is should we throw away the > current IDL fixed format and replace it with a generic fixed point > type. No, definitely not. I don't think anyone suggested to throw away fixed, but to add a generic version of that. > The second argument is, assuming we don't replace fixed is > how to provide generic mechanisms to support DynFixed and CDR > streams. > > Let me consider the second argument first, just to get it out of the > way. Since we are assuming here that fixed is here to stay > (again, > for the sake of the argument), the question is whether the current > DynFixed get/set_value and the proposed read/write_fixed solve the > problem at hand. > > For DynFixed, I could see a second pair of operations: > > string get_string_value(); > void set_string_value raises(InvalidValue); > > that would allow the application to get and set the value as a > string. > This would provide additional flexibility to the application. I > could > also see each language mapping providing a helper function (if > necessary) to convert the string or the OctetSeq to and from a > generic > fixed point value, for languages that provide a fixed point value. That would be a pragmatic solution to the current octet sequence dilemma. However, keep in mind that the idea of setting/getting fixed values into and out of DynAnys was no more than a workaround born of necessity. If a generic fixed type had been available, that would have been used instead (I have this on good authority from the author of the relevant DynFixed operations). > For read/write_fixed, using any seems to be the exactly correct solution > given the constraints above. When you consider the intended use of CDR > streams, which is to support marshalling OBV values, this doesn't seem > to add overly much overhead. I am not sure that using any is the exactly correct solution. It works, most definitely. But it also loosens the type system a lot. If (for whatever reason) I would like to have the following: // Not legal IDL interface foo { void op(in fixed p1); // Accept any kind of fixed }; I can't write this, so I am forced to write interface foo { void op(in any p1); // Must pass a fixed type here }; The problem I see is that this allows me to pass all sorts of things other than fixed, so quite a bit of type safety is lost. > Now, back to the first question, should we scrap fixed and replace > it with a generic fixed. I see several arguments against this: > > 1. The digits and scale are useful to provide an explicit contract in > the IDL source of the range of values permitted. Completely agree. Throwing it away is not the answer. > 2. The Ada language, in particular, does not support a generic fixed > point type, only a type with a fixed digits and scale. That doesn't count here, in my opinion. Just because Ada doesn't have a generic fixed point type does mean there shouldn't be one. Otherwise, by the same reasoning, we could argue that the should be no fixed-point types of any kind at all, because after all, C++ doesn't have them. > 3. A generic fixed point value is going to be larger than one limited > to a specific digits and scale. Yes. That's the price you pay for genericity. Also, I'd like to point out that sending a fixed value inside an any requires even *more* space than a generic fixed-point type would. I would at least entertain the idea of adding a generic fixed type for a while longer, and maybe consider how that would map to the different languages before we throw the idea away. It may well turn out not to stack up. Fine -- if so, we axe it. But I don't think we know that a generic fixed type is bad yet, and we have two cases so far where it would be useful. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 22:17:38 -0700 From: Jonathan Biggar To: Michi Henning CC: mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type References: Michi Henning wrote: > > For read/write_fixed, using any seems to be the exactly correct > solution > > given the constraints above. When you consider the intended use > of CDR > > streams, which is to support marshalling OBV values, this doesn't > seem > > to add overly much overhead. > > I am not sure that using any is the exactly correct solution. It > works, > most definitely. But it also loosens the type system a lot. If (for > whatever reason) I would like to have the following: > > // Not legal IDL > interface foo { > void op(in fixed p1); // Accept any kind of fixed > }; > > I can't write this, so I am forced to write > > interface foo { > void op(in any p1); // Must pass a fixed type > here > }; > > The problem I see is that this allows me to pass all sorts of things > other > than fixed, so quite a bit of type safety is lost. I'm only proposing this fix for the specific problem of CDR streams. For other interfaces, you could use OBV to create a generic fixed. > > Now, back to the first question, should we scrap fixed and replace > > it with a generic fixed. I see several arguments against this: > > > > 1. The digits and scale are useful to provide an explicit contract in > > the IDL source of the range of values permitted. > > Completely agree. Throwing it away is not the answer. > > > 2. The Ada language, in particular, does not support a generic fixed > > point type, only a type with a fixed digits and scale. > > That doesn't count here, in my opinion. Just because Ada doesn't have > a generic fixed point type does mean there shouldn't be one. Otherwise, > by the same reasoning, we could argue that the should be no fixed-point > types of any kind at all, because after all, C++ doesn't have them. That's a red herring argument. C++ doesn't have them, but we are free to define one for C++. This isn't really the case for Ada, exactly. > > 3. A generic fixed point value is going to be larger than one limited > > to a specific digits and scale. > > Yes. That's the price you pay for genericity. Also, I'd like to point > out that sending a fixed value inside an any requires even *more* space > than a generic fixed-point type would. Not too much, just 8 bytes. > I would at least entertain the idea of adding a generic fixed type > for a while longer, and maybe consider how that would map to the > different languages before we throw the idea away. It may well turn > out not to stack up. Fine -- if so, we axe it. But I don't think we > know that a generic fixed type is bad yet, and we have two cases > so far where it would be useful. No, you really have only one case, for your example (from private email) of trying to define a generic remote device measurement protocol in IDL. The DynFixed and CDR stream stuff is just corner cases, that most programmers won't ever stumble on. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 15:45:19 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998, Jonathan Biggar wrote: > I'm only proposing this fix for the specific problem of CDR streams. > For other interfaces, you could use OBV to create a generic fixed. That idea has merit I think, at least if we can assume that OBV is ubiquitous (which may not happen for another year or more). > > > 2. The Ada language, in particular, does not support a generic fixed > > > point type, only a type with a fixed digits and scale. > > > > That doesn't count here, in my opinion. Just because Ada doesn't have > > a generic fixed point type does mean there shouldn't be one. Otherwise, > > by the same reasoning, we could argue that the should be no fixed-point > > types of any kind at all, because after all, C++ doesn't have them. > > That's a red herring argument. C++ doesn't have them, but we are free > to define one for C++. This isn't really the case for Ada, exactly. But if we can defined a generic fixed-point type for C++, surely we can defined one for Ada as well? > > > 3. A generic fixed point value is going to be larger than one limited > > > to a specific digits and scale. > > > > Yes. That's the price you pay for genericity. Also, I'd like to point > > out that sending a fixed value inside an any requires even *more* space > > than a generic fixed-point type would. > > Not too much, just 8 bytes. OK, I admit it isn't a lot. A special-purpose encoding for a generic fixed would probably add two bytes (one for digits, one for scale). Given that the fixed-point value consumer a byte for every pair of digits, an 8-byte overhead is probably tolerable. > No, you really have only one case, for your example (from private email) > of trying to define a generic remote device measurement protocol in > IDL. The DynFixed and CDR stream stuff is just corner cases, that most > programmers won't ever stumble on. I agree with the DynFixed and CDR stuff being corner cases. Since you mentioned it, I'll toss the measurement idea into the ring publicly: Suppose we want to create a domain-specific standard for remote sensing of some kind. There are sensors that measure height, weight, temperature, etc. We want to use fixed-point types because that gives us an indication of the precision of the measurement. Of course, I can write IDL like this: typedef fixed<6,3> TemperatureType; interface TemperatureSensor { TemperatureType get_temp(); }; We can create the whole spec this way. Only problem is that two years later, everyone decides to upgrade to new sensors with better precision and range. To accommodate the upgrade, we have to change the whole spec for the new types: typedef fixed<8,4> NEW_TemperatureType; interface NEW_TemperatureSensor { TemperatureType get_temp(); }; If I could have a generic IDL fixed-point type, the problem goes away: typedef fixed TemperatureType; // Can hold any kind of fixed interface TemperatureSensor { TemperatureType get_temp(); }; Note that I don't want to abolish specific fixed-point types at all. I just would like to *add* a generic fixed-point type that acts as a root for all fixed-point types, similar to the way CORBA::Object acts as a root for interface types. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 23:19:28 -0700 From: Jonathan Biggar To: Bill Janssen CC: Michi Henning , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type References: Bill Janssen wrote: > > I just would like to *add* a generic fixed-point type that acts as > > a root for all fixed-point types, similar to the way CORBA::Object > > acts as a root for interface types. > > Why, for heaven's sake? Don't we have enough odd special cases in > the > type system already? Don't be misled by the seemingly small, but in > reality only regular, differences between different fixed-point > types. > Why should there be a generic fixed-point type when we don't have > generic sequence types or enumeration types? Good point. Even though different fixed point types have similar interfaces (they store d digits with s scale), it is not a good idea to encourage people to think of them as just slight variations of the same type. This type of thinking makes bankers very nervous. > Incidentally, I dislike the proposed generic fixed constants for this > very reason. Actually, I'm not proposing them as new, just fixing up what was there. > Excerpts from local.omg: 13-Jul-98 Re: Custom marshalling supp.. Michi > Henning@dstc.edu.a (3441*) > > > To accommodate the upgrade, we have to change the whole > > spec for the new types: > > > typedef fixed<8,4> NEW_TemperatureType; > > > interface NEW_TemperatureSensor { > > TemperatureType get_temp(); > }; > > Sure, because the old calculations were written taking the the old > precision into mind -- just what an interface is all about. If the > precision changes, we'll need to change our use of it, too. Right. There are likely to be lots of hidden assumptions in the applications about the precision and scale of the values. In most problem domains, you should be able to figure out what scale and precision you are going to use and stick with it. Trying to mix fixed<31,0> and fixed<31,31> isn't going to be very fruitful. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 13 Jul 1998 23:12:46 PDT Sender: Bill Janssen From: Bill Janssen To: Jonathan Biggar , Michi Henning Subject: Re: Custom marshalling support for IDL fixed type CC: mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com References: Excerpts from local.omg: 13-Jul-98 Re: Custom marshalling supp.. Michi Henning@dstc.edu.a (3441*) > I just would like to *add* a generic fixed-point type that acts as > a root for all fixed-point types, similar to the way CORBA::Object > acts as a root for interface types. Why, for heaven's sake? Don't we have enough odd special cases in the type system already? Don't be misled by the seemingly small, but in reality only regular, differences between different fixed-point types. Why should there be a generic fixed-point type when we don't have generic sequence types or enumeration types? Incidentally, I dislike the proposed generic fixed constants for this very reason. Excerpts from local.omg: 13-Jul-98 Re: Custom marshalling supp.. Michi Henning@dstc.edu.a (3441*) > To accommodate the upgrade, we have to change the whole > spec for the new types: > typedef fixed<8,4> NEW_TemperatureType; > interface NEW_TemperatureSensor { > TemperatureType get_temp(); }; Sure, because the old calculations were written taking the the old precision into mind -- just what an interface is all about. If the precision changes, we'll need to change our use of it, too. Bill Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 16:21:21 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998, Bill Janssen wrote: > Excerpts from local.omg: 13-Jul-98 Re: Custom marshalling supp.. Michi > Henning@dstc.edu.a (3441*) > > > I just would like to *add* a generic fixed-point type that acts as > > a root for all fixed-point types, similar to the way CORBA::Object > > acts as a root for interface types. > > Why, for heaven's sake? Don't we have enough odd special cases in the > type system already? Don't be misled by the seemingly small, but in > reality only regular, differences between different fixed-point types. > Why should there be a generic fixed-point type when we don't have > generic sequence types or enumeration types? How else do we do a generic fixed-point type? Sending it as any or octet sequences isn't all that pretty in my book. > Incidentally, I dislike the proposed generic fixed constants for this > very reason. > > Excerpts from local.omg: 13-Jul-98 Re: Custom marshalling supp.. Michi > Henning@dstc.edu.a (3441*) > > > To accommodate the upgrade, we have to change the whole > > spec for the new types: > > > typedef fixed<8,4> NEW_TemperatureType; > > > interface NEW_TemperatureSensor { > > TemperatureType get_temp(); > }; > > Sure, because the old calculations were written taking the the old > precision into mind -- just what an interface is all about. If the > precision changes, we'll need to change our use of it, too. Hmmm... But by the same argument, we shouldn't have unbounded strings either: interface foo { // Hypothetical IDL void op1(in string s); // ILLEGAL, because it's // not necessary. void op2(in string<10> s); // OK }; Remember, Pascal did exactly that, until people learned the hard way that it wasn't practical and introduced an open array concept. The point is that fixed<8,4> is *too* specific. I would like to have a more generic way that doesn't open the type system up too much (like using type any). In other words, I want a parameter type that says "Any kind of fixed type is OK here", as opposed to one that says "Absolutely anything is OK here". There would be nothing to prevent me to still use fixed<8,2> if that would be appropriate. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 13 Jul 1998 23:26:40 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Michi Henning Subject: Re: Custom marshalling support for IDL fixed type CC: Jonathan Biggar , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com References: Excerpts from direct: 13-Jul-98 Re: Custom marshalling supp.. Michi Henning@dstc.edu.a (2425*) > How else do we do a generic fixed-point type? We don't. If the Type Extensions submitters wanted that, they would have submitted it that way. > Hmmm... But by the same argument, we shouldn't have unbounded strings > either: We don't have unbounded strings, do we? We just have a default bound of 0xFFFFFFFF. > The point is that fixed<8,4> is *too* specific. So far, the evidence you've adduced for that assertion isn't very convincing. I think it's just fine -- just the right specificity. Bill Return-Path: Date: Mon, 13 Jul 1998 23:28:47 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Custom marshalling support for IDL fixed type CC: Michi Henning , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com References: <35AAF870.A2EB0810@floorboard.com> Excerpts from direct: 13-Jul-98 Re: Custom marshalling supp.. Jonathan Biggar@floorboa (1920*) > > Incidentally, I dislike the proposed generic fixed constants for this > > very reason. > Actually, I'm not proposing them as new, just fixing up what was there. Yes, I understand, Jon. I was suggesting that ``what was there'' should be viewed as an error, and that we should only allow fixed-point constants of specific fixed-point types. Bill Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 14 Jul 1998 16:45:06 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type On Mon, 13 Jul 1998, Bill Janssen wrote: > > The point is that fixed<8,4> is *too* specific. > > So far, the evidence you've adduced for that assertion isn't very > convincing. I think it's just fine -- just the right specificity. OK, I'm ready to cave in. You win :-) But *please* let's add helper functions to the language mappings so I get away from the octet sequence stuff on DynFixed. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Tue, 14 Jul 1998 09:05:24 -0700 From: Jonathan Biggar To: Bill Janssen CC: Michi Henning , mmihic , obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.com Subject: Re: Custom marshalling support for IDL fixed type References: <35AAF870.A2EB0810@floorboard.com> Bill Janssen wrote: > Yes, I understand, Jon. I was suggesting that ``what was there'' > should > be viewed as an error, and that we should only allow fixed-point > constants of specific fixed-point types. Because it really doesn't matter whether fixed point constants have a explicitly declared type. The spec already gives them an implicitly declared type, which is the smallest digits and scale that holds the complete value. For most languages, which map fixed to a generic fixed point type, this makes not one whit of difference. The only language left, Ada, happens to have a generic fixed point constant format, even though it doesn't have a generic fixed point type, so it still doesn't make any difference. My proposal for fixing the ORB core fixed point issues also requires that fixed point constant folding be done using "double-precision" arithmetic, so that no precision is lost. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA0033C10C1338A5 Date: Tue, 14 Jul 1998 14:55:10 PDT Subject: Re: Custom marshalling support for IDL fixed type To: michi@dstc.edu.AU cc: jon@floorboard.COM, mmihic@iona.COM, obv-rtf@omg.org, orb_revision@omg.org, vinoski@iona.COM Your example that wants a generic fixed-point type doesn't seem to me to be specific to remote sensing. The idea of tracking, but not statically fixing, precision pervades the physical sciences. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 15 Jul 1998 09:21:38 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type On Tue, 14 Jul 1998, Jonathan Biggar wrote: > My first question is why would you want to use fixed point for this > rather than floating point? The main argument for decimal fixed > point > types is to avoid rounding and representation problems caused by > attempting to store decimal values in a binary representation. But > the > primary application for decimal calculations is banking, not > instrumentation. It seems to me that your remote sensor application > would work just fine using long double and not using fixed point. You could use floating point. But then you would also have to add some other parameter to indicate the accuracy of the measurement, which is often important. Just because a floating-point value can have up to n digits of precision, that doesn't mean the device that sent the value has measured it to that accuracy. Fixed-point would be useful for that, because there is always a stated accuracy implicit in the type of the value. > Is there anyone out there with direct experience with remote > instrumentation protocols that can tell us whether the data > retrieved is > primarily binary or decimal? I'd like to know too. If there is no common need to represent measurement values as fixed-point values, then the measurement example goes out the window, any many of the arguments in favour of a generic fixed-point type disappear. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA0089EA0AFA37B9 Date: Tue, 14 Jul 1998 16:45:42 PDT Subject: Re: Custom marshalling support for IDL fixed type To: michi@dstc.edu.AU cc: Mike_Spreitzer.PARC@xerox.com, obv-rtf@omg.org, orb_revision@omg.org > ... experience with remote instrumentation protocols ... ... is not the only relevant experience, as you have already agreed with me. Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA0089EA0B1737B9 Date: Wed, 15 Jul 1998 00:21:04 PDT Subject: Re: Custom marshalling support for IDL fixed type To: nash@hursley.ibm.COM cc: Mike_Spreitzer.PARC@xerox.com, obv-rtf@omg.org, orb_revision@omg.org > it allows the fixed value to be sent (albeit > with the overhead of the TypeCode). So you're proposing to change the CDR for fixed values to include typecodes? Eek! Return-Path: Date: Tue, 14 Jul 1998 15:18:05 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Jonathan Biggar Cc: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <35AA1B2D.94CB31D1@mailserver.hursley.ibm.com> <35AA345F.BACFB8E9@floorboard.com> <35AA4EA7.5D727FCA@mailserver.hursley.ibm.com> <35AA54E7.CBE8DBBA@floorboard.com> Jonathan, Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Jonathan (and Steve), > > Thanks for the IDL lesson :-) In that case, I withdraw my > proposal, > > since OBV custom marshalling already has operations for writing > and > > reading the any type. > > No, you still need the proposal, since using read/write_any will not > result in the correct information inserted into the CDR stream. To > clarify: > > write_fixed(in any val); > > would encode into the CDR stream the value of the fixed point type > contained in the Any, but: > > write_any(in any val); > > would encode into the CDR stream a TypeCode, followed by the value > in > the any, which is a different result. > Yes, it's different, but it allows the fixed value to be sent (albeit with the overhead of the TypeCode). The other approach would be to use a string of octets, as Jeff suggested. It seems that we should live with one or other of these until the whole issue of "fixed" is re-addressed, not try to add this as an OBV RTF thing. So once again I withdraw the proposal that I made to the OBV RTF. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Wed, 15 Jul 1998 13:43:46 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Mike_Spreitzer.PARC@xerox.com Cc: nash@hursley.ibm.com, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <98Jul15.002138pdt."53217(2)"@alpha.xerox.com> Mike, Not at all. I'd just be sending them as an any, whose CDR does include a typecode. Simon Mike_Spreitzer.PARC@xerox.com wrote: > > > it allows the fixed value to be sent (albeit > > with the overhead of the TypeCode). > > So you're proposing to change the CDR for fixed values to include > typecodes? Eek! -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 08:35:04 -0700 From: Jonathan Biggar To: nash@hursley.ibm.com CC: Mike_Spreitzer.PARC@xerox.com, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <98Jul15.002138pdt."53217(2)"@alpha.xerox.com> <35ACA402.EE3D9DBC@mailserver.hursley.ibm.com> Simon Nash wrote: > > Mike, > Not at all. I'd just be sending them as an any, whose CDR does > include a typecode. That just seems plain silly. Now you are throwing out the baby with the bathwater, just because there isn't a generic fixed point type, you aren't going to accept using an any to insert and extract a fixed point value into/from a CDR stream without the TypeCode? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 16 Jul 1998 14:03:26 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Jonathan Biggar Cc: Mike_Spreitzer.PARC@xerox.com, obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Custom marshalling support for IDL fixed type References: <98Jul15.002138pdt."53217(2)"@alpha.xerox.com> <35ACA402.EE3D9DBC@mailserver.hursley.ibm.com> <35ACCC28.736FB2EB@floorboard.com> Jonathan, All I am saying is that this is a workaround that people can use today if they want to send fixed point values. If someone wants to make a proposal for improving on this, in the context of fixing the various other problems with fixed types (or not, as they choose), that is fine with me and I may well decide to support it. However, I have withdrawn the proposal that I made, because it is clear that it has larger implications than this one API, and I don't have the best view of the "big picture". Simon Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Mike, > > Not at all. I'd just be sending them as an any, whose CDR does > > include a typecode. > > That just seems plain silly. Now you are throwing out the baby with > the > bathwater, just because there isn't a generic fixed point type, you > aren't going to accept using an any to insert and extract a fixed > point > value into/from a CDR stream without the TypeCode? > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb