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
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
On 15/08/06, Edward Slattery [EMAIL PROTECTED] 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
On 15/08/06, Edward Slattery [EMAIL PROTECTED] 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
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
On 15/08/06, Edward Slattery [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] wrote:
In the case of SDO, it was just
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,
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
10 matches
Mail list logo
