Michael, I'm looking at this and have a question. I'm a little confused with the Int/IInteger/BigDecimal/Decimal changes. For instance, I see we would no longer define a type "commonj.sdo#BigDecimal" as this would be "commonj.sdo#Decimal" ? In the spec I have BigDecimal is still mentioned (actually as I type this I come to the conclusion that the spec is incosistent and the references to the SDO Abstract Type BigDecimal should probably not be there.).
We do still have commonj.sdo#Integer as an SDO Type ... but there is no Type enum returned for this???? So if I create one I can't determine it's type using getTypeEnum??? Seems odd. Cheers, On 24/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > Hi, > > I updated a patch for TUSCANY-1368. If someone could review and apply it > that would be great. > > Thanks, > > Michael > Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - > HydraSDO > > -----Original Message----- > From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Friday, August 24, 2007 2:50 PM > To: [email protected] > Subject: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class > interface Type off-spec enum values > > > [ > https://issues.apache.org/jira/browse/TUSCANY-1368?page=com.atlassian.ji > ra.plugin.system.issuetabpanels:all-tabpanel ] > > Michael Yoder updated TUSCANY-1368: > ----------------------------------- > > Attachment: TUSCANY-1368.txt > > This patch updates the Type.h interface to be spec compliant. Enum > values and public members not in the spec are removed from the > interface. Also related/ripple 2.1 spec changes: > - commonj.sdo#Int type added to factory (maps to enum Types::IntType) > - commonj.sdo#BigInteger type rennamed commonj.sdo#Integer (maps to enum > Types::BigInteger) > - commonj.sdo#BigDecimal type renamed commonj.sdo#Decimal (maps to enum > Types::BigDecimal) > - set/getInteger accessors renamed to set/getInt (map to commonj.sdo#Int > and xsd:int) > > > > > C++ SDO portability: class interface Type off-spec enum values > > -------------------------------------------------------------- > > > > Key: TUSCANY-1368 > > URL: > https://issues.apache.org/jira/browse/TUSCANY-1368 > > Project: Tuscany > > Issue Type: Improvement > > Components: C++ SDO, C++ Specification > > Affects Versions: Cpp-M3 > > Reporter: Michael Yoder > > Fix For: Cpp-Next > > > > Attachments: TUSCANY-1368.txt > > > > > > C++ SDO specification class interface Type has enum values > ("OpenDataObjectType", "num_type")which are not in the specification, > and are being used externally by SCA. It would seem that for SDO > portability these should be taken internal to SDO or submitted to the > spec committee. > > -----Original Message----- > > From: Pete Robbins [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 21, 2007 9:21 AM > > To: [email protected] > > Subject: Re: SDO spec compliance/portability: Type enums the num_type > > is just a convenient way to know the extent of an enum and is common > practice. I guess the OpenDataObjectType must be a Tuscany specific > extension to handle open types. I'd need to do some research to > determine if this is missing from the spec or can be removed. > > Please raise a Jira for the renaming of IntegerType. > > It may be useful to raise Jiras for all these issues so we can track > them. > > Cheers, > > On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > The Tuscany SDO C++ class Type::Types enum has these values which do > > > > not appear in the C++ 2.1 specification: > > > > > > - OpenDataObjectType > > > - num_type > > > > > > Would it be appropriate to file a bug to remove the additional > values? > > > Or alternatively a bug for them to be submitted to the spec > > > committee? > > > > > > In addition the 2.1 spec renamed the enum value "IntegerType" to > > > "IntType". > > > > > > Would it be appropriate to file a bug to have this value renamed? > > > > > > Thanks, > > > > > > Michael Yoder > > > Software Developer > > > Rogue Wave Software > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Pete > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
