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.
> > http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancemen
> >t#New_Menu_API_.28and_its_design_problems.29
> >
> > Today [in d...@openoffice.org] 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
> > redesign.
>
> 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)
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.
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.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
