[Kde-bindings] Splitting up the Smoke qt library into modules

[Richard Dale]

On Wednesday 21 October 2009 08:12:23 pm Arno Rehn wrote:
> On Wednesday 21 October 2009 19:36:35 Richard Dale wrote:
> > While we're discussing BIC changes to the smoke libs, I wonder if it
> > would be a good idea to split up the libsmokeqt library into small libs.
> > The small size of the Smoke libs is becoming a big advantage relative to
> > other bindings libraries, and it we split them up a bit maybe the
> > advantage would  be larger still. Or is the a performance tradeoff in
> > that searches for a class or method would have to cross Smoke module
> > boundaries more often and that would slow things down? It is worth
> > measuring somehow?
> 
> Since it's all cached once it has been looked up, I doubt that the
>  performance tradeoff is noticable.
It only cached fully in the Qyoto bindings. There is a different cache scheme 
in QtRuby and PerlQt (not sure about PHPQt).

> > For a start I really thing we should remove QtXml and QtSql from the base
> > Smoke library as nearly all dynamic languages have their own versions of
> >  there which are quite likely to be better than a wrapped C++ version.
> > For example, there in no point in using the QtSql classes in Ruby because
> > Rails ActiveRecord is so much better.
> 
> With the new smokegenerator that should be a trivial task, so we could
>  split everything at once.
> 
> > Then the decision is whether it is a good idea to map one Qt module onto
> >  one Smoke library.
> 
> I don't see anything that would speak against it.
Yes, if we find performance problems we can either attempt to tune, or revert.

> > One example for me, is that I think a separate QtCore smoke library would
> >  be useful for Semantic web applications, as I could use the Ruby
> > bindings for QtCore, Soprano with the ActiveRDF Virtuoso adaptor with
> > Wt::Ruby for the web app without the overhead of the QtGui library.
> 
> If we're at it I think we should also split the C# assembly into qtcore,
> qtgui, qtsql etc.
Yes, I agree.

-- Richard