Re: C++ SDO spec compliance/portability: SDORuntimeException
Pete, Cattle-prod of high voltage required for the spec team then. ;-) Yours, Mike. Pete Robbins wrote: I agree Mike but the SDO spec does not currently define a set of headers that are compilable so adding in things like constructors/destructors is necessary. When we have a set of headers from the spec group we should use those to replace the current Tuscany headers. Until then we should aim to get them as close as possible. Cheers, On 22/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, My 10 cents is that it is not right to add methods to the spec API classes. My view would be that compliance would require spec-defined classes to provide the spec, the whole spec and nothing but the spec. This is certainly the approach to compliance taken for most Java APIs. It's OK to have officially defined extension points - the classic one is the interface / implementation split - but in general, if some object is supposed to be an implementation of the spec, then that is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. Pete Robbins wrote: > Michael, > > An interesting set of questions! I'm not convinced that adding methods to > the spec api classes is a compliance issue (in fact it may be impossible to > implement without modifying the spec apis ... constructors etc.) but it > could be a portability issue if it is not clear that the methods are > implementation specific. > - 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]
Re: C++ SDO spec compliance/portability: SDORuntimeException
I agree Mike but the SDO spec does not currently define a set of headers that are compilable so adding in things like constructors/destructors is necessary. When we have a set of headers from the spec group we should use those to replace the current Tuscany headers. Until then we should aim to get them as close as possible. Cheers, On 22/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, My 10 cents is that it is not right to add methods to the spec API classes. My view would be that compliance would require spec-defined classes to provide the spec, the whole spec and nothing but the spec. This is certainly the approach to compliance taken for most Java APIs. It's OK to have officially defined extension points - the classic one is the interface / implementation split - but in general, if some object is supposed to be an implementation of the spec, then that is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. Pete Robbins wrote: > Michael, > > An interesting set of questions! I'm not convinced that adding methods to > the spec api classes is a compliance issue (in fact it may be impossible to > implement without modifying the spec apis ... constructors etc.) but it > could be a portability issue if it is not clear that the methods are > implementation specific. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: C++ SDO spec compliance/portability: SDORuntimeException
Folks, My 10 cents is that it is not right to add methods to the spec API classes. My view would be that compliance would require spec-defined classes to provide the spec, the whole spec and nothing but the spec. This is certainly the approach to compliance taken for most Java APIs. It's OK to have officially defined extension points - the classic one is the interface / implementation split - but in general, if some object is supposed to be an implementation of the spec, then that is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. Pete Robbins wrote: Michael, An interesting set of questions! I'm not convinced that adding methods to the spec api classes is a compliance issue (in fact it may be impossible to implement without modifying the spec apis ... constructors etc.) but it could be a portability issue if it is not clear that the methods are implementation specific. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: C++ SDO spec compliance/portability: SDORuntimeException
Thanks Pete,
Yes, these issues I am putting together and posting came up when doing a
portability study using HydraSDO to build Tuscany SCA. Since the SDO
spec is separate from SCA, we were thinking this would be a good goal.
That seems to mean making them internal to Tuscany SDO or taking them to
the committee.
Michael
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 9:02 AM
To: tuscany-dev@ws.apache.org
Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods
to the spec api classes is a compliance issue (in fact it may be
impossible to implement without modifying the spec apis ... constructors
etc.) but it could be a portability issue if it is not clear that the
methods are implementation specific.
The methods below are added so that an SDORuntimeException can contain a
"stack" of locations indicating where it was thrown/rethrown etc.. These
are only used within the Tuscany implementation so I guess could be
moved to protected and make the classes that use them friends?? I'm not
sure how useful these are anyway but the exception class pre-dates it
being used for SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException& e)
{
cout << e;
}
I like the simplicity of this but I guess we could write an SDOUtils
method to do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> The Tuscany SDO C++ class SDORuntimeException has these public member
> functions which do not appear in the C++ 2.1 specification:
>
>
> SDO_API severity_level getSeverity() const; SDO_API void
> setSeverity(severity_level sev); SDO_API void setMessageText(const
> std::string& msg_text); SDO_API void setExceptionLocation(const
> std::string& file,
>unsigned long line,
>const std::string& function="");
> SDO_API void setLocation(const std::string& file,
> unsigned long line,
> const std::string& function="");
>
> SDO_API void trace(const std::string& text="%1:\n %3 %4 %2");
>
> SDO_API virtual ostream& PrintSelf(ostream &os) const; SDO_API friend
> ostream& operator<< (ostream &os, const SDORuntimeException &except);
>
>
> What's the rational behind these additional member functions? Would it
> be appropriate to file a bug to have them removed from the public API?
> Or alternatively a bug for them to be submitted to the spec committee?
>
> Thanks,
>
> Michael Yoder
> Software Developer
> Rogue Wave Software
>
> -
> 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]
Re: C++ SDO spec compliance/portability: SDORuntimeException
Michael,
An interesting set of questions! I'm not convinced that adding methods to
the spec api classes is a compliance issue (in fact it may be impossible to
implement without modifying the spec apis ... constructors etc.) but it
could be a portability issue if it is not clear that the methods are
implementation specific.
The methods below are added so that an SDORuntimeException can contain a
"stack" of locations indicating where it was thrown/rethrown etc.. These are
only used within the Tuscany implementation so I guess could be moved to
protected and make the classes that use them friends?? I'm not sure how
useful these are anyway but the exception class pre-dates it being used for
SDORuntimeException.
There are also methods to allow simple streaming:
catch(SDORuntimeException& e)
{
cout << e;
}
I like the simplicity of this but I guess we could write an SDOUtils method
to do something similar instead.
I'm not sure if any of these should be mandated by the specification.
Cheers,
On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
Hi,
The Tuscany SDO C++ class SDORuntimeException has these public member
functions which do not appear
in the C++ 2.1 specification:
SDO_API severity_level getSeverity() const;
SDO_API void setSeverity(severity_level sev);
SDO_API void setMessageText(const std::string& msg_text);
SDO_API void setExceptionLocation(const std::string& file,
unsigned long line,
const std::string& function="");
SDO_API void setLocation(const std::string& file,
unsigned long line,
const std::string& function="");
SDO_API void trace(const std::string& text="%1:\n %3 %4 %2");
SDO_API virtual ostream& PrintSelf(ostream &os) const;
SDO_API friend ostream& operator<< (ostream &os, const
SDORuntimeException &except);
What's the rational behind these additional member functions? Would it
be appropriate to file a bug to have them removed from the public API?
Or alternatively a bug for them to be submitted to the spec committee?
Thanks,
Michael Yoder
Software Developer
Rogue Wave Software
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
