Xdg-list digest, Vol 1 #432 - 11 msgs
otaylor at redhat.com
Wed Jul 23 15:12:34 EEST 2003
On Wed, 2003-07-23 at 06:19, David Faure wrote:
> On Wednesday 23 July 2003 06:43, Linas Vepstas wrote:
> > Do you actually have a proposal for something better?
> Yes - what about splitting glib? IMHO it's fine to have a lib that provides
> linked lists and other containers, for C programs and libraries (if it is indeed
> proven that low-level libraries like Xr, freetype or Xft will want to use it).
> But declaring as "standard" a library that patches up an incomplete home-made object
> concept on top of a language that doesn't support objects, is nonsense: if people
> want to use objects, they have a real OO programming language for that: C++.
Shouldn't you switch to C# then, instead of using a library that
emulates events, properties, etc, on top of an overcomplicated language
that none-the-less is missing these basic features? ;-)
GObject really shows its power when connecting *different* languages
together, and the important features there (introspection, standardized
memory management, standardized ways of attaching extra data to objects,
etc) are features that C++ doesn't have in it's raw form.
But as I said earlier, I don't really expect to convince anybody who
hasn't used GObject themselves of that.
The main point here, is no splitting the GLib distribution doesn't makes
sense; the bulk of download-time / compile-time / install disk space
isn't libgobject anyways, and it *is* a separate library.
> Between this and the "LSB wants to standardize on GTK" news, it's a bit difficult
> not to see political agendas being pushed....
The news about what? If they do, they haven't talked to me about it. (*)
I really wouldn't read conspiracy in a few people who are excited about
GLib, and want to promote it; I'd agree with you that we should let this
subject drop and return to areas where there is consensus.
(I guess not I'm not setting a good example of letting inflammatory
statements pass without responding to them above...)
(*) To prevent future misunderstanding, let me be clear, I'm not denying
that the LSB could possibly be interested in including GTK+ among the
many libs of the LSB; I have no information either way. I'm just saying
it's not something that the GTK+ team has pushed or so far been
involved with in any ways.
More information about the xdg