[wx-discuss] wxTNG: using external libraries

[Vadim Zeitlin]

On Fri, 17 Feb 2006 08:54:04 +0000 Julian Smart <julian at anthemion.co.uk> wrote:

JS> Here are some concerns about use of external libraries:

 Let me start by stating a few things which are probably obvious to
everyone but still might be worth mentioning:

0a) The goal is to concentrate our efforts on wx "core competences", that
    is allowing writing full-featured portable C++ programs. Note that I
    don't think we should limit ourselves solely to the GUI stuff (there
    is also wxBase) but IMO we shouldn't be writing container/string
    classes, socket and thread classes and probably database classes
    neither.

 b) The above gives the broad direction but the decision still needs to be
    taken about each individual component separately. If we use some boost
    classes, it doesn't mean that we should use all of them, e.g. boost::
    filesystem::path stuff is an abomination (from personal experience of
    working with it) and is really not better than wxFileName (which has
    its own problems too, of course...). So for every non-GUI class we'll
    have the choice of
	(i) using std or boost class, if any
	(ii) using another third-party library
	(iii) making the class modular and allow it to use multiple
	      backends to avoid introducing dependency on another library
	(iv) continuing to use our own class
	(v) submitting our own class into, for example, boost, if it's
	    really much better than the existing class or if there are
	    no existing alternatives

    And I think that in practice all of the above will be used in different
    contexts so let's not even try to find one solution for everything, it
    won't work

 c) We want to avoid heavy dependencies on too many other libraries,
    especially when they are not optional.


JS> 1. By basing our future on libraries like boost, we're
JS> tying ourselves to them and have to commit to their
JS> future direction, whatever that might be. What if their
JS> license changes,

 This shouldn't be a problem with boost, at least, as their goal is to
develop classes suitable for inclusion into future C++ standard library and
for this the license must be even more liberal than wx one.

JS> or they make some other decision we don't like?

 This is a real possibility, of course. In particular, boost doesn't have
the same vision of backwards compatibility as we do, they're quite ready to
break it (and sometimes pretty much so) if they deem it to be necessary.
All I can say is that we should be careful and only use the classes with
proven history behind them and hope they remain stable.
 
JS> 2. Do these libs support all our platforms? (For example,
JS> embedded ones.)
JS> 
JS> 3. Will we have to drop support for any significant compilers?

 I think both of these questions have the same answer: if a library doesn't
work on important target systems or can't be built with a significant
compiler, then we can't use it. It's important, however, to define which
targets are important and which compilers significant. I don't know about
the targets but I do think we should limit ourselves only to modern C++
compilers, otherwise all this wxTNG effort doesn't make much sense. For me
"modern" means gcc4-comparable and definitely excluds VC6 and gcc < 3.4,
for example.


JS> 4. What about overhead? STL-based apps can increase
JS> in size significantly. How would this affect embedded
JS> apps?

 In theory, using templates smartly shouldn't increase the size.

JS> What about library and app compilation speed?

 This will definitely go out of the window, no doubt about it. It will be
many times slower than now, probably. But this is just the price to pay.

JS> 5. What about overall coherence of the API? It becomes
JS> a collection of libraries, probably with different
JS> documentation sets that may be a pain to navigate around.

 True. Another reason to avoid depending on (or at least isolating the user
from) too many libraries.

JS> Similarly, we would need to clarify licensing carefully.

 I'm more concerened about the build issues...

JS> 6. What happens when the external libraries don't do
JS> things we need them to do? (If we want to change them
JS> we have to straddle several projects, and we might not
JS> get permission.)

 For any important library we want to use we absolutely must discuss with
that library developers beforehand. This includes boost and I do realize we
may have troubles communicating with them. But we need to try...

JS> 7. Existing users have to learn new stuff.

 The idea is to use only libraries common enough so that there are already
a lot of users knowing them and, indeed, to facilitate life for the users
who already use them and wx together in their programs.

JS> The main arguments for external libraries are (AFAIK):
JS> 
JS> 1. They're better than our classes. (Sure, but are they
JS> so much better? Are people beating their head against
JS> the restrictions and if so, can we have some examples?)

 wxSocket. Should I say more?

JS> 2. It'll be easier for us to maintain. (Except we also
JS> have to maintain bridge classes, and be aware of changes/bugs
JS> in these other libraries.)

 Still, for non trivial libraries it should be easier in the long term.
Also, in some cases there will be no bridge classes.

JS> 3. People don't have to learn new APIs. (What proportion
JS> of potential users are already using the classes we intend to use?)

 If we consistently choose the best library for the given functionality, we
can be reasonably sure that more of them use it than wx equivalent.

JS> 4. It looks good if we follow standards. (Hm.. Microsoft seem pretty
JS> successful making it up as it goes along, but of course
JS> it's a slightly more powerful organisation :-))

 Yes, if I were Microsoft I'd do the same thing as they did -- that is
created .NET just to have something different and something they could
totally control. We don't have the resources to do what they did though,
nor do I necessarily dream of locking everybody in the way they do.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org