Thanks for your reply (my computer has been dead since last week, and
I've just waded through 1300+ emails).
OK - I'm convinced that if I go for a GObject-based approach, I should
use GOB2 rather than hand-coding the classes. But I'm not yet convinced
about the merits of GObject as opposed to, say C# or Python.
I'm concentrating on getting a tarball release of the current code out,
rather than big cleanups, so I won't be switching for a while.
Dave
On Tue, 2003-05-27 at 16:00, George wrote:
> On Sat, May 24, 2003 at 01:47:39PM +0000, Dave Malcolm wrote:
> > Possibly a silly question, considering who I'm asking :-)
>
> Possibly :)
>
> > I'm the lead programmer on Conglomerate (www.conglomerate.org), a free
> > (as in GPL/LPGL) user-friendly XML editor. We're hoping to make
> > something that former Word users can easily migrate to, for editing
> > DocBook and other formats.
>
> nice!
>
> > Currently the code is in C, and uses GTK+ and GNOME libraries. There
> > are various places where classes and inheritance get used, though they
> > are currently implemented using structs and hand-coded v-tables, rather
> > than GObject. I'm about to do a big rewrite of a substantial part of
> > the code.
> >
> > I'm considering several options for my classes:
> > - port to C++ and use that
> > - port to C# and use Mono
> > - port to GObject by hand
> > - port to GObject using GOB2
> > - port to Python
> >
> > I've had a brief play with GOB2, and I'm quite fond of the GOB2
> > approach. But something that concerns me is how few projects seem to be
> > using GOB2. There also doesn't seem to be an archive of this mailing
> > list, and the "minimalist" nature of the website makes the project come
> > across as a bit of an experiment, rather than a reliable tool.
> >
> > I'm a bit scared of introducing such a vital dependency into my project
> > Are there any testimonials out there from satisfied users?
> >
> > I'm sorry if this comes across as a bit negative; please understand that
> > I want only the best for my project!
>
> I fully understand. First let me explain the lack of projects using gob, and
> note not all of them are listed on the page, for example gnome-vfs uses gob.
> I think people are 1) scared of anything called a preprocessor 2) scared of
> an extra dependency. #1 can't be solved since that's irrational fear. If
> you're afraid of preprocessors you'd better not even use C though. #2 can be
> solved by just including gob with your sources. This is what gnome-vfs does,
> you can just stick gob into the distributed source tree and so anyone can
> still compile and hack on the project without needing to get gob. Lot of
> people are however afraid of gob because it is not a "clean" solution. Which
> it is not, it is a pragmatic solution. It is a way to create GObject based
> classes in C. If I were to implement another object system for gob, I
> wouldn't use GObject. In fact I wouldn't write gob, I'd use one of the
> existing languages that implements classes in the language syntax, like C++,
> Python, C# or Java. GOB is a way to get things done, not an entry into
> competition for perfect language design.
>
> If you are afraid of the minimalist web page, that is because I'm not much of
> a webmonkey. I would say that gob should be a reliable tool and I used it in
> several projects myself (this was my original reason for writing gob). I
> don't have that much time currently due to school and so I don't maintain 5
> million projects as I did a few years ago (count currently stands at 3:), so
> I don't use gob currently (I don't have a need for it in gdm nor genius
> currently, but if I ever do need it, I will definately use it).
>
> So the point is: if you wish to use GObject, I'd suggest GOB2. Writing
> GObjects by hand is lots of needless pain which brings about many bugs
> because of typos (I can rant long hours on the evils of C varargs and the way
> GObject uses them, and the way they can screw you up if you do GObjects by
> hand). However if you don't mind not using C and GObject, I'd suggest going
> with one of the oo languages. One reason for GOB2 was to be able to write
> libraries that are as easily bindable as any other GObject C library. If you
> don't care about language interoperability, don't care about using GObject,
> and don't care about C in particular, I don't see a reason to use gob :)
> Now if I was starting a project with lots of classes, I'd probably still
> pick C and GOB2 myself since I'm much more at home in C then anything else.
>
> As for the testimonials, of course I'd be biased :)
>
> George
-- Dave Malcolm <david_at_davemalcolm.demon.co.uk>Received on Tue Jun 03 2003 - 14:31:37 CDT
This archive was generated by hypermail 2.2.0 : Sun Apr 17 2011 - 21:05:02 CDT