Hi Mathias, > Means: I also would like to see a bit more flexibility - not as a > creeping process but as a "built-in" ability where API users can see > where they can rely on type safety and compatibility and where they can't.
+1 >> However, for high level services, I am pretty sure the non-availability >> of optional interfaces/properties would have given us an inflation of >> Foo2/3/4/5 services (I'm quite sure I would have reached the number 5 or >> higher a few times - my services usually *live* and evolve). This would >> have made the API more complex, more difficult to understand (for its >> user), more difficult to describe and implement (for its implementor) - >> for no good reason except some theoretic arguing. > > It wouldn't make it more complex, IMHO having a service with a lot of > optional interfaces is more complex than having several services with a > clear description of its function set. "more" does not need "more > complicated", often it's exactly the opposite. Hmm. In most of the cases I encountered, I would have had to introduce services like FooOOo10, FooOOo11, FooOOo20, and so on. Simply because for a new version, the (highly OOo-specific) service Foo was extended. I always did this with introducing optional interfaces/properties, which, as you say, is unnecessarily complex. However, introducing those "versioned" services is so, too. Simply extended the existing service is the only thing which isn't. > I fail to understand how this is related to the question whether we need > "old style" services. It isn't at all - that's why I changed the summary of my mail :) > Possible boundaries between "OOo specific" and > "non-OOo-specific" are too unsharp to judge your comment. I wouldn't > like to let API users guess. That's a good point. I like Stephan's idea of making this explicit by introducing another syntactical element. > In case of compatibility we not only deal with implementors but also > with "clients". I agree with you that most of our services and > interfaces can be changed incompatibly without damaging existing > implementations using them as indeed in most cases there are no such > implementation outside of OOo. > > But how shall we deal with client code? What's our "story" about that? > Before we examine the content of Pandora's box in closer detail here - > can we agree to move that discussion into another thread? Hmm - my minimal definition of thread is "different subject" :), but I prepared this mail to not contain references to the old thread. So, let's open this box: IMO, something along those lines (not thought to an end): - We should allow for minor incompatible changes which can be overcome with re-compiling the client code (like adding properties) - we should allow for non-minor incompatible changes which need adjustments in the client code for major updates only - we should disallow silent semantical changes in the API/implementation (this one is hard to ensure even today, except by policy, which can be ignored by its very nature) Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
