Frank Schönheit - Sun Microsystems Germany wrote: > Hi Mathias, > >> Good examples: MediaDescriptor and EmbeddedObjectContainer in comphelper. > > Are you volunteering to introduce those two helper? :)
No. Meanwhile I think we should better have some UNO services replacing the helper classes. Wrapper classes for UNO interfaces or services mostly indicate that the API is too cumbersome and a more user friendly one is needed. Real C++ helpers for UNO constructs should be used only to convert them to genuine C++ constructs (like Sequence -> STL vector). Any helper that works on UNO objects and provides a different API to them that is not a genuine C++ API should better be carried out as a UNO service. >> A (maybe unwanted) side effect of moving libraries to the SDK is that >> you must be more careful when you change them. > > moving into the SDK should be done after careful discussion of the > interface only, and the interface should be complete (in all conscience) > at the moment we do so. In this case, changes might be seldom enough to > accept this side effect. That's exactly what I wanted to express: the necessity to have the interface "complete" may limit the number of possible SDK helpers a lot. Changes in these classes are comparably painful as UNO API changes (though theoretically possible). Thanks for expressing this better than I did. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
