[Kde-bindings] Splitting up the Smoke qt library into modules
Arno Rehn
arno at arnorehn.de
Wed Oct 21 19:12:23 UTC 2009
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.
> 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.
> 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.
--
Arno Rehn
arno at arnorehn.de
More information about the Kde-bindings
mailing list