Rainman Lee wrote:
Hi Frank,
Thank you for your replay.
Hoping to see your marcos soon~ hehe.
i am not fan of macros and the skeletonmaker can be already used for
both (declaration and forwarding).
I think it is no real overhead and changes are not so often. I agree
that it would be or can be smart for the developer but not for people
who wants to read/understand or debug the code later on.
Anyway i will think about it ...
Juergen
Best Wishes, Rainman.
On Fri, Aug 1, 2008 at 5:15 AM, Frank Schönheit - Sun Microsystems
Germany <[EMAIL PROTECTED]> wrote:
Hello Rainman,
We are developing our products upon UNO component model.
One of the big problem we have met is how to implement a service which
declared by the NEW STYLE statement.
...
Now the problem comes, this is a terrible multiple inheritance
relationship in C++, and maks hardly reuse of ImplA. because of ImplA
and XB both derived from XA,
leading that we must implement all methods declared in XA within ImplB
again.The same problem occurs in ImplC.
If there are many methods in XA, the development and the maintenance
complexity of the ImplB and ImplC would be unacceptable.
This in fact is a big problem, IMO.
Upon continued begging the skeletonmaker tool (which is part of the SDK)
is meanwhile able to generate code for you which does the forwarding
(the concrete syntax evades me at the moment), which somewhat relaxes
the problem.
However, very high on my personal wishlist would be a define,
auto-generated into XFoo.hpp, which allows me to write something like
FORWARD_XFOO( <base_class_name> )
, which effectively implements all methods of XFoo, just forwarding them
to "base_class_name". This would reduce the maintenance efforts to mere
re-compilation.
(And while we are at it, an
DECLARE_XFOO()
would be great, too, also coming from the .hpp file. Yes, I know that
skeletonmaker can also generate all the member declarations, but that's
again a maintenance problem if the interface changes, which happens
often enough during development of new API.)
So I just wonder whether we really need the single interface service.
Well, as much as I dislike the additional effort during implementation:
The question is whether it's worth the added convenience for the
*client* of your API. Remember that new-style API is usually much more
convenient to use, and that usually, you implement only once, or a few
times, but your clients use your API much more often. Your decision,
finally.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
