Re: [Re: [libxml++] UTF8 support]

[Murray Cumming <murrayc usa net>]

Ed Hill <ed eh3 com> wrote:
> --------------------------------------------- 
>	Attachment:  
>	MIME Type: multipart/signed 
> --------------------------------------------- 
> On Sun, 2003-02-23 at 01:59, Murray Cumming wrote:
> > On Sun, 2003-02-23 at 03:31, Stefan Seefeld wrote:
> > > 
> > > I hope this clarifies my suggestion a bit.
> > 
> > Yes, we should consider it. So far I can think of these 2 disadvantages:
> > - All implementation is via templates in headers - so we can't fix it
> > just by installing a new version - applications must be recompiled.
> 
> 
> And how is that any different than what you're doing now?

Shared or "dynamic libraries" allow
- sharing of executable code to save systm resources.
- updating of those shared implementations without recompiling of client
applications. For instance, you don't need to rebuild Gnumeric when you
install a bugfix release of GNOME.

I have major reservations about forcing people to recompile their apps to use
new minor stable releases of libxml++. This is a general problem with
templates though. Later, after we've talked about it, I might ask for a vote
if we have not been able to make a clear decision or compromise.

>  Your current
> paint-yourself-into-a-corner implementation doesn't allow any wholesale
> switching of Unicode libraries through either compile-time options or 
> run-time binding.

Yes, I understand what Stefan wants to do. Stefan understands that it has
disadvantages.
 
> In contrast, Stefan's idea provides compile-time switching.  And its
> sooo easy to implement.
> 
> 
> > - The API would be less clear (But, it works for std::string)
> 
> 
> Hardly.  This is exactly what the standard library does for string--they
> template based on the type. 

Yes, I said it works for std::string. However, :
1. Most people use std::string  rather than basic_string<>. But we could
provide similar default typedefs in headers:
For instance:
libxmlpp_glibmm.h could have xmlpp::glibmm::dom_parser and
xmlpp::glibmm::node, etc.
and libxmlpp_qt could have xmlpp::qt::dom_parser and xmlpp::qt::node, etc.
(Though qt actually includes its own XML parser so they won't have much need
for libxml)
2. The interface for std::string is simpler than libxml++ for most uses,
mostly because std::string is just one class and libxml++ is a bunch of
classes that work together.
3. It looks like Doxygen can cope well with templates so the API might not be
less clearly documented. GNU haven't documented basic_string yet, but here's
an example of basic_istream:
http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/classstd_1_1basic__istream.html
4. I would like to hear about other examples other than Glib::ustring and
QString, particularly because I doubt that anyone wants to use QString with
libxml++. We should only solve problems that really exist. Stefan, what string
class are you using?

> And since libxml++ is, after all, a C++
> project then why restrict yourself to some half-assed subset of C++
> syntax just because you, Murray, haven't taken the time to familiarize
> yourself with it.

I am quite familiar with C++. What are you suggesting that I am not familiar
with?

> I realize that I'm "just another observer" here but its still sad to
> watch as Stefan keeps trying to move this little project in a better
> direction only to receive constant abuse from Murray 

Stefan behaved inappropriately in the past. Some of this he has acknowledged.
It wasn't all his fault - the correct process was not used. Most recently I
asked repeatedly for contribution and in this thread we finally received it.

> in the form of
> irrelevant (the mostly-OT discussion of Qt strings above was deleted
> from this email

I'm not sure what discussion of Qt strings you are referring to.

> ) and/or moronic responses like the ones above.

I really don't see what's moronic about pointing out that template
implementations are not part of shared libraries, but part of the headers.

> Libxml++ could become a nice, clean alternative to Xerces-C++ but until
> more of Stefan's ideas get implemented I'm afraid projects should prefer
> the latter.  Or just deal with the C API of libxml2.

I am all for Stefan helping. Please tell me how we can help him to help more.
Feel free to tell me what would be a more appropriate response, at the time.
BUT, this does not include just allowing him to run wild over the code. 


Murray Cumming
murrayc usa net
www.murrayc.com