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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
