Re: [libxml++] Vote: templates everywhere v. Glib::ustring: results + I'm back

[Christophe de VIENNE <cdevienne alphacent com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Nice to see that the list has been so active during my absence, even if I had 
more than a hundred mails to read... Thank you all.

Le Mardi 4 Mars 2003 18:40, Murray Cumming Comneon com a écrit :
> This won't actually happen for a little while, so I'm still ready to see
> more votes, but at the moment the underwhelming response is like so:
>
> A (Glib::ustring) : 2
> B (templates everywhere) : 3
> C (Don't care) : 0
>
> When I add my own finally-decided A vote that makes it undecided. I'm
> fairly confident that our maintainer Christophe de Vienne will vote A when
> he gets around to it so that would make the result lean slightly towards A.
> Any one else could interpret the vote completely differently, but this is
> not a court of law. If it is then I am Judge Nutmeg.

Concerning this vote, strictly choosing between A and B is difficult. However 
my choice go to A after attentive read of the concerned threads.
But before the definitive choice, I would really like the discussion about an 
intermediate solution, with specialized classes for glib::ustring and QString 
in a library, and the possibility to use the fully templated classes, to go 
to a conclusion.
This solution may be a bit heavy for us but will have advantages of both 
alternative.

> Again, 1.0 will happen first anyway, but at the moment I'm thinking of
> this: -  libxml++ 1.2 (or maybe we'll call it 2.0 to allow for emergency
> API-breaking-and-refreezing for 1.0) will use Glib::ustring.
> -  If they feel like doing the work, some people will fork
> libxml++_templated, which should be parallel installable with libxml++,
> with a different library name, headers directory, and pkg-config .pc file.
> I'm happy for this fork to exist in the libxml++ cvs but with a completely
> separate module/directory name. Hopefully we can steal ideas from each
> other as the APIs develop.

In the case we choose one alternative I completely agree with this.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ZydFB+sU3TyOQjARArBVAKC+MX76iYfkrHsUtwKWPqej1TZHRgCdE1xb
uNZJbTD21W/jpQt52hskt1k=
=8cP8
-----END PGP SIGNATURE-----