You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/08/12 00:16:38 UTC
[C++] Design of SCA and SDO public API classes
I noticed two different patterns in the definition of the public SCA and
SDO API classes.
SCA:
A delegation pattern where the public API class delegates calls to an
implementation class.
For example ComponentContext contains a private pointer to
ComponentContextImpl. ComponentContextImpl implements the methods from
ComponentContext but does not extend ComponentContext.
SDO:
Inheritance, where the implementation class extends the public API class.
For example DataFactoryImpl extends DataFactory.
Is there any particular reason for the two different patterns? Any
advantages or issues with one compared the other?
A related question. What do you think about reorganizing the folder
structure a little to clearly separate the spec includes from the
implementation specific ones?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Design of SCA and SDO public API classes
Posted by Pete Robbins <ro...@googlemail.com>.
>
> > A related question. What do you think about reorganizing the folder
> > > structure a little to clearly separate the spec includes from the
> > > implementation specific ones?
> > >
>
>
yes that would make sense. The osoa/sca tree should only contain what is
defined in the spec.
Cheers,
Re: [C++] Design of SCA and SDO public API classes
Posted by Pete Robbins <ro...@googlemail.com>.
That's about it. The SCA spec says that you actually get instances of e.g.
ComponentContext so we need to delegate to the ComponentContextImpl. As SDO
was returning pointers inheritence works fine.
Cheers,
On 14/08/06, Edward Slattery <ed...@googlemail.com> wrote:
>
> In the case of SDO, it was just the logical pattern for implementation
> hiding.
>
> The implementation was fine up to the point where we wanted to start
> thinking about
> the static SDO api, and were proposing to allow code generators to inherit
> from some DataObject base class and add their own methods such as
> "getName()" etc.
>
> We cant do that with DataObject, as all the DataObject pointers given out
> are really
> DataObjectImpls. The prototype code I put in the test directory uses
> containment instead
> of inheritance to allow a MyDataObject to contain a reference to a
> DataObject, and delegate
> its DataObjectish behaviour.
>
> cheers,
> Ed.
>
> On 11/08/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > I noticed two different patterns in the definition of the public SCA and
> > SDO API classes.
> >
> > SCA:
> > A delegation pattern where the public API class delegates calls to an
> > implementation class.
> > For example ComponentContext contains a private pointer to
> > ComponentContextImpl. ComponentContextImpl implements the methods from
> > ComponentContext but does not extend ComponentContext.
> >
> > SDO:
> > Inheritance, where the implementation class extends the public API
> class.
> > For example DataFactoryImpl extends DataFactory.
> >
> > Is there any particular reason for the two different patterns? Any
> > advantages or issues with one compared the other?
> >
> > A related question. What do you think about reorganizing the folder
> > structure a little to clearly separate the spec includes from the
> > implementation specific ones?
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
--
Pete
Re: [C++] Design of SCA and SDO public API classes
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/08/06, Edward Slattery <ed...@googlemail.com> wrote:
> OK, so if we dont deal with exception hiding, the two are:
>
> Employee employee = someSDOmethod_returningMyTypesafeDO();
> cout << employee->getName() << endl;
>
> DataObjectPtr employee = someSDOmethod_returningAnSDO();
if (employee)
{
> cout << employee->getString("name") << endl;
}
is necessary.
> ..so Im not sure that type safety really increases maintainability that
> much that a developer would be willing to introduce a custom step into the
> build process, and maintain generated code with all the resulting issues
> of
> upward compatibility, debugging code you didn't write, getting inevitable
> bugs fixed in the generator in a timely way etc.
>
> Im not saying typesafe is wrong, I just dont want to see it developed in
> the
> C++ world because its cool in the java world.
>
> Theres no design for it yet - but maybe the value in doing it will become
> clearer to me if we start discussing that amongst the community.
Absolutely. Unless there is a valid use case then we shouldn't go ahead and
implement it.
--
Pete
Re: [C++] Design of SCA and SDO public API classes
Posted by Edward Slattery <ed...@googlemail.com>.
OK, so if we dont deal with exception hiding, the two are:
Employee employee = someSDOmethod_returningMyTypesafeDO();
cout << employee->getName() << endl;
DataObjectPtr employee = someSDOmethod_returningAnSDO();
cout << employee->getString("name") << endl;
..so Im not sure that type safety really increases maintainability that
much that a developer would be willing to introduce a custom step into the
build process, and maintain generated code with all the resulting issues of
upward compatibility, debugging code you didn't write, getting inevitable
bugs fixed in the generator in a timely way etc.
Im not saying typesafe is wrong, I just dont want to see it developed in the
C++ world because its cool in the java world.
Theres no design for it yet - but maybe the value in doing it will become
clearer to me if we start discussing that amongst the community.
On 15/08/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> On 15/08/06, Edward Slattery <ed...@googlemail.com> wrote:
> >
> >
> > This leads to a question which should be asked.
> >
> > If the MyDataObject contains a DataObject, and all typesafe calls such
> as
> > getName() are in fact delegated via
> containedobject->getString("name")...
> > what has type safety actually gained us? We had to do a codegen to
> > generate
> > the wrapper class, the calls are no more efficient than the dynamic API.
> > All
> > we really gain is the ability for the compiler to grumble if we type
> > getNome() instead of getName() in our user program.
> > For the sake of an aditional set of tooling to be run prior to
> > compilation,
> > and probably a set of integration tools to make that work from DevStudio
> > as
> > a pre-build step, and Eclipse etc - is the benefit worth the work? What
> do
> > the C++ community feel?
>
>
> The benefit is simplification of the programming for the end user. It is a
> lot cleaner and more maintainable to code
>
> Employee employee = someSDOmethod_returningMyTypesafeDO();
> cout << employee.getName() << endl;
>
> than
> DataObjectPtr employee = someSDOmethod_returningDOPtr();
> try
> {
> if (employee != NULL)
> {
> cout << employee->getString("name") << endl;
> }
> }
> catch (SDORuntimeException &e)
> {
> }
>
> OK... I've assumed the exception handling is in the static SDO methods but
> even so you can see what I'm getting at. Maybe we need a thread on what
> TypeSafe SDO means for C++. Is there a spec/design?
>
> Cheers,
>
> --
> Pete
>
>
Re: [C++] Design of SCA and SDO public API classes
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/08/06, Edward Slattery <ed...@googlemail.com> wrote:
>
>
> This leads to a question which should be asked.
>
> If the MyDataObject contains a DataObject, and all typesafe calls such as
> getName() are in fact delegated via containedobject->getString("name")...
> what has type safety actually gained us? We had to do a codegen to
> generate
> the wrapper class, the calls are no more efficient than the dynamic API.
> All
> we really gain is the ability for the compiler to grumble if we type
> getNome() instead of getName() in our user program.
> For the sake of an aditional set of tooling to be run prior to
> compilation,
> and probably a set of integration tools to make that work from DevStudio
> as
> a pre-build step, and Eclipse etc - is the benefit worth the work? What do
> the C++ community feel?
The benefit is simplification of the programming for the end user. It is a
lot cleaner and more maintainable to code
Employee employee = someSDOmethod_returningMyTypesafeDO();
cout << employee.getName() << endl;
than
DataObjectPtr employee = someSDOmethod_returningDOPtr();
try
{
if (employee != NULL)
{
cout << employee->getString("name") << endl;
}
}
catch (SDORuntimeException &e)
{
}
OK... I've assumed the exception handling is in the static SDO methods but
even so you can see what I'm getting at. Maybe we need a thread on what
TypeSafe SDO means for C++. Is there a spec/design?
Cheers,
--
Pete
Re: [C++] Design of SCA and SDO public API classes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 15/08/06, Edward Slattery <ed...@googlemail.com> wrote:
>>
>> Im not saying that inheritance wouldnt work in SCA - it probably would.
>
>
> I'm saying it wouldn't work ;-)
>
> As the spec stands you get an INSTANCE of ComponentContext returned from
> getCurrent(). So we either us no inheritance and just code up the
> implementation in ComponentContext or we use containment to get the
> implementation separation. Even if getCurrent() returned a
> ComponentContextImpl it's methods would not get called once it was
> assigned
> as a ComponentContext.
>
> If the spec stated that a pointer was returned then we could use
> inheritance.
>
> Cheers,
>
I see, got it. After so many years programming Java I have to think C++
again :) Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Design of SCA and SDO public API classes
Posted by Pete Robbins <ro...@googlemail.com>.
On 15/08/06, Edward Slattery <ed...@googlemail.com> wrote:
>
> Im not saying that inheritance wouldnt work in SCA - it probably would.
I'm saying it wouldn't work ;-)
As the spec stands you get an INSTANCE of ComponentContext returned from
getCurrent(). So we either us no inheritance and just code up the
implementation in ComponentContext or we use containment to get the
implementation separation. Even if getCurrent() returned a
ComponentContextImpl it's methods would not get called once it was assigned
as a ComponentContext.
If the spec stated that a pointer was returned then we could use
inheritance.
Cheers,
--
Pete
Re: [C++] Design of SCA and SDO public API classes
Posted by Edward Slattery <ed...@googlemail.com>.
Im not saying that inheritance wouldnt work in SCA - it probably would.
The issue we ran into with SDO was that we have built a system in which the
class which is visible to the user of the library is DataObject, they can
only work with that API, and dont know about DataObjectImpls. What they are
given when they create a DataObject is a DataObjectPtr - which looks like a
pointer to a DataObject to them, but is in reality a pointer to a
DataObjectImpl, so that when they call methods on it - the DataObjectImpl
does the work. (DataObject is pure abstract).
Now, in C++, extensions to the DataObject, such as a typesafe API for a
specific type of DataObject, cannot be included in the sdo library, which is
a binary, so the only option is that the user uses the exposed API of the
library in some way. If this way were to be inheritance from the only object
they can see (DataObject), then they would have to implement all the
abstract methods getInteger, getBoolean etc themselves, as these are only
implemented in DataObjectImpl.
The other solution is containment, where they get a DataObject from the sdo
library, and include it in their typesafe "MyDataObject", then delegate all
incoming calls to getInteger etc to the contained object. (This contained
object will in reality be a DataObjectImpl).
This leads to a question which should be asked.
If the MyDataObject contains a DataObject, and all typesafe calls such as
getName() are in fact delegated via containedobject->getString("name")...
what has type safety actually gained us? We had to do a codegen to generate
the wrapper class, the calls are no more efficient than the dynamic API. All
we really gain is the ability for the compiler to grumble if we type
getNome() instead of getName() in our user program.
For the sake of an aditional set of tooling to be run prior to compilation,
and probably a set of integration tools to make that work from DevStudio as
a pre-build step, and Eclipse etc - is the benefit worth the work? What do
the C++ community feel?
On 15/08/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Edward Slattery wrote:
> [snip]
> > In the case of SDO, it was just the logical pattern for implementation
> > hiding.
> >
> > The implementation was fine up to the point where we wanted to start
> > thinking about
> > the static SDO api, and were proposing to allow code generators to
> > inherit
> > from some DataObject base class and add their own methods such as
> > "getName()" etc.
> >
> > We cant do that with DataObject, as all the DataObject pointers given
> out
> > are really
> > DataObjectImpls. The prototype code I put in the test directory uses
> > containment instead
> > of inheritance to allow a MyDataObject to contain a reference to a
> > DataObject, and delegate
> > its DataObjectish behaviour.
> >
> > cheers,
> > Ed.
> >
>
> Just to confirm I understand this correctly:
>
> Are you saying that inheritance was the logical pattern for
> implementation hiding in SDO?
> But then this caused a problem for generated code? Can you describe the
> problem with having the pointers inherit from DataObjectImpl vs contain
> a DataObjectImpl?
>
> Also if inheritance was the logical pattern for implementation hiding in
> SDO, why wouldn't it work the same way for SCA?
> Maybe I'm missing something but I'm not seeing why inheritance would not
> work for ComponentContext as well. Could you please explain?
>
> Thanks,
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [C++] Design of SCA and SDO public API classes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Edward Slattery wrote:
[snip]
> In the case of SDO, it was just the logical pattern for implementation
> hiding.
>
> The implementation was fine up to the point where we wanted to start
> thinking about
> the static SDO api, and were proposing to allow code generators to
> inherit
> from some DataObject base class and add their own methods such as
> "getName()" etc.
>
> We cant do that with DataObject, as all the DataObject pointers given out
> are really
> DataObjectImpls. The prototype code I put in the test directory uses
> containment instead
> of inheritance to allow a MyDataObject to contain a reference to a
> DataObject, and delegate
> its DataObjectish behaviour.
>
> cheers,
> Ed.
>
Just to confirm I understand this correctly:
Are you saying that inheritance was the logical pattern for
implementation hiding in SDO?
But then this caused a problem for generated code? Can you describe the
problem with having the pointers inherit from DataObjectImpl vs contain
a DataObjectImpl?
Also if inheritance was the logical pattern for implementation hiding in
SDO, why wouldn't it work the same way for SCA?
Maybe I'm missing something but I'm not seeing why inheritance would not
work for ComponentContext as well. Could you please explain?
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Design of SCA and SDO public API classes
Posted by Edward Slattery <ed...@googlemail.com>.
In the case of SDO, it was just the logical pattern for implementation
hiding.
The implementation was fine up to the point where we wanted to start
thinking about
the static SDO api, and were proposing to allow code generators to inherit
from some DataObject base class and add their own methods such as
"getName()" etc.
We cant do that with DataObject, as all the DataObject pointers given out
are really
DataObjectImpls. The prototype code I put in the test directory uses
containment instead
of inheritance to allow a MyDataObject to contain a reference to a
DataObject, and delegate
its DataObjectish behaviour.
cheers,
Ed.
On 11/08/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> I noticed two different patterns in the definition of the public SCA and
> SDO API classes.
>
> SCA:
> A delegation pattern where the public API class delegates calls to an
> implementation class.
> For example ComponentContext contains a private pointer to
> ComponentContextImpl. ComponentContextImpl implements the methods from
> ComponentContext but does not extend ComponentContext.
>
> SDO:
> Inheritance, where the implementation class extends the public API class.
> For example DataFactoryImpl extends DataFactory.
>
> Is there any particular reason for the two different patterns? Any
> advantages or issues with one compared the other?
>
> A related question. What do you think about reorganizing the folder
> structure a little to clearly separate the spec includes from the
> implementation specific ones?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>