Ariel Constenla-Haile wrote:
Hello Juergen,

On Sunday 18 January 2009 09:50, Juergen Schmidt wrote:
I know my design is awful and looks complicated, but that's the best I
could imagine in the current OOo API design/situation; vid.

Today [in] Jürgen suggested "an incompatible change
and redesign of the toolkit or a complete new one. First and foremost
should we make use of the UNO "ease of use" features, means multiple
inheritance, service constructor etc. to make it more comfortable and
easier to use."
well, this have to be seen in the correct context. If we really think
about a replacement of VCL and if we want a clear separation between UI
and core via an abstract layer than i would suggest that we start with a
  incompatible redesign or a new UNO toolkit. And of course we should
then allow incompatible changes over years to allow fixing design errors.

The awt module is just a reflection of the global situation in OOo API,
or how do we interpret things like css.ucb.XSimpleFIleAccess/2/3 ... n?
When will it stop? when they reach XSimpleFileAccess30?
Of course css.ucb.SimpleFIleAccess/XSimpleFileAccess cannot be changed
because they are published, the same goes for css.awt.X/PopupMenu and
css.awt.X/MenuBar, so IMHO the published/unpublished concept should be
or it should be used more accurately. An interface that is intended for
public use and not published after 4 years is questionable.

this is not the underlying problem. Of course it may be confusing for an API client why some API is unplushed after a long time. But once I asked a developer, he answered that leaving a service unpublished was the only way to add functionality as the implementation evolved (instead of declaring this new functionality to be Optional, or design an XSomthing2/3/4...n)
i think there is no 100% solution. Sometimes it might be better to let an API as it is even it is not 100% perfect. But changing it would bring only a minimal advantage but a lot of work in many areas.

From my point of view API design is a main part of a new feature implementation and we should spent more time on it. We should take it more serious ... An implementation can be changed easier later.

OOo API describes an abstract specification, but on the other hand it's not that abstract in the sense that there are different vendor's implementations; in this sense OOo API describes concrete impls. inside OOo project only, so it has to evolve as OOo evolves.

Besides evolving, some stablished things may/should be redisign to take advantage of service constructors and multiple inheritance.
sure and some of these changes would be possible compatible. Ok compatible in the sense of no necessary changes in client code because a createInstance would still work.

With things like
XDocument Document.create() to create a new doc. and get access to *all* its functinality
XDocument Document.create(URL aURL) to load an existing one form its URL
etc. etc.
OOo will win more enthusiastic developers.
sure i 100% agree and Andreas Schluens has already started to change the document services etc. But all this is a lot of work and often the developers has other priorities.

We know the advantages very well at least some of us but we have to find a common agreement. And that is not only an agreement of developers that develop for but also the ones they work with or simply use the API. If nobody has problems to adapt the own code from time to time, lets say with a new major version, we can of course start to think about redesigning a lot of API's.

The last time i asked how people think about it was at OOCon in Barcelona and the answer was that people (mainly API users) like the compatibility statement and our commitment to compatible API's.

But over the time we see more and more disadvantages and we recognize that it becomes impossible to provide good, complete and easy to use API's ...

We need a clear and well communicated concept how can handle incompatible API changes and when we want allow them. That includes well documented migration steps, examples etc.



To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to