Mathias Bauer wrote: > I don't know what "discouraging" means. At the end developers choose the > language they prefer, and if we don't forbid to use C++, people will > continue to choose it at times. And as I hope you don't ask for > forbidding C++, we have the obligation to not break it intentionally. > Hi Mathias,
discouraging means just that: make people aware of the mentioned drawbacks, and encourage them to use another implementation language. Otherwise, agreed, with the exception that we actually *do* talk about *intentionally* breaking API compatibility in the first place! > If an OOo release came with an API that is incompatible to a > large extent, we could also change the C++ binding incompatibly - as > well as any other language binding. But changing the C++ binding with > every release just because "it's fragile anyway" isn't a good idea. > I'm not proposing that. But to reiterate: it's much easier to break c++ than any other language binding. See for example the "adding a new method to an interface" change Frank was talking about - no prob for all the language bindings, _except_ c++. > Maybe it's harder to deal with C++ than with e.g. Java. But that > shouldn't be a reason not to try it. > Sure. Still, I think c++ should carry less weight (compared to e.g. Java or Python), when it comes to deciding whether an incompatible change is worth it - like balancing the pain a core dev has with a badly designed interface, vs. the effort an external component provider has when adapting to that change. I actually very much like the idea of only catering for actively maintained extensions; which would make the mere re-compilation of a c++ extension against a new SDK almost a non-issue to me. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
