Re: [GNOME VFS] gob inside gnome-vfs ...

[Ian McKellar <yakk yakk net>]

On Wed, 2002-06-19 at 02:06, Michael Meeks wrote:
> Hi Ian / Seth,
> 
> On Tue, 2002-06-18 at 19:31, Ian McKellar wrote:
> > Because we want to use GObject in GnomeVFS now and GOB is a sensible way
> > of writing GObjects (not the only sensible way, but one of them).
> 
> 	Hmm. Have you looked at what Nautilus does with GNOME_CLASS_BOILERPLATE
> ? that and GNOME_CALL_PARENT substantially reduces the amount of GObject
> boilerplate code you have to type - to the level that I would be
> surprised if gob buys you anything - except perhaps writing your headers
> and accessors for you. 

I haven't looked at that stuff. Does it take care of signals and
inheritance and stuff for us too?
> 
> 	I can only believe that gob makes much sense, if you intend to
> radically re-structure your API frequently - which I would view as a
> pretty terrible idea (wrt. bin/API-compat :-). Is it possible to
> consider choosing another sensible way ?

Well gob lets me think about what I'm designing rather than worry about
what I'm typing. I can design the API to be easy to use rather than easy
to implement because when I'm writing GObjects by hand I tend to worry
about implementation complexity - because the more complex the
implementation is the more mistakes I make.
> 
> > I asked Seth this too and aparently thats what George recommended. Are
> > you complaining that we didn't add a dependancy? ;-)
> 
> 	No - in fact, I loathe gob - as you can probably tell :-) and keeping
> it well out of the dependency stack is a great idea from my perspective.

Why do you loathe gob? I haven't heard any real arguments against it
apart from "its a preprocessor" which seems like a bit of a red herring
when we depend on both orbit-idl and the c preprocessor so heavilly in
GNOME and gob does a better job of keeping out of my way than those two.
> 
> > I'm not how much discussion is really required for a dependancy thats 
> > only there if you build from CVS. It wouldn't affect the development 
> > platform or even packagers at all. But with the cvs include we don't 
> > even change the build process for people who build from CVS. 
> 
> 	Well - the thing is that should I decide to re-write all of bonobo in
> Pascal, with some built in P2C processing so we ship generated C, would
> you start getting twitchy ? How about writing it in lisp and then
> converting it ? I hope someone would wrestle me to the ground and batter
> some sense into me :-)

If there were decent arguments I probably wouldn't be too upset. If it
made the source easier to maintain, more readable and accessible to more
developers then I would probably be in favour of it. I don't think (as
you can see) that straight C is the best language for everything. I
think that its lacking a lot if you want to do object oriented
programming - such as objects for a start :) Gob lets us express the
objects we want to write simply. They're not too complex, theyre
> 
> 	I understand one of the large factors in the sawfish / metacity
> decision, was un-maintainability due to it being written in a foreign
> language. Given that we have a very broad cross section of hackers
> actually doing the maintenance on gnome-vfs, looking at the ChangeLog in
> recent times I see: 
> 
> 	George Lebl, Jody Goldberg, Kristian Rietveld, Ian McKellar, 
> 	Alex Gravely, Seth Nickell, Mark McLoughlin, myself, Anders 
> 	Carlsson 
> 
> 	It would be great if we could all be taught / explained the need for
> gob to, very carefully, and in words of one syllable. I am personally
> prepared to spend some considerable time de-gobbing it / doing whatever
> you think it saves you manually, if only to ensure consistancy,
> debugability, maintainability etc.

C+GObject is a foreign language. I'm slowly learning it. It *is* a
barrier to many people getting involved in GNOME development it seems. I
personally love the GObject object model - its one of my favourites. I
hate the syntax though. GOB is (in my opinion) just a better syntax for
C+GObject. If you're familiar with C+GObject it doesn't take much at all
to understand GOB. If you're familiar with both GObject and Java then
gob is trivial. Additionally gob is one of the best documented parts of
GNOME. Its certainly better documented than GObject. 
> 
> 	For example trying to build HEAD to take a butchers at the generated
> code, I just got:
> 
> In file included from gnome-vfs-method.gob:18:
> gnome-vfs-method.h:42: syntax error before `typedef'
> In file included from gnome-vfs-method.gob:22:
> ../libgnomevfs/gnome-vfs-module.h:46: parse error before `*'
> cc1: warnings being treated as errors
> ../libgnomevfs/gnome-vfs-module.h:46: warning: type defaults to `int' in
> declaration of `vfs_module_init'
> ../libgnomevfs/gnome-vfs-module.h:46: warning: data definition has no
> type or storage class
> ../libgnomevfs/gnome-vfs-module.h:70: parse error before `*'
> 
> 	Which leaves me gob-smacked, [ ;-> ], now of course, if that was normal
> C I could instantly fix the problem [ presumably 
> GNOME_VFS_METHOD_GET_CLASS is not being automagically substituted for
> something meaningful ]. Presumably that means that HEAD is not building
> - or I got something badly wrong 

I think its was just an error when Seth was gobifying gnome-vfs-module.
That line in the GOB file sticks out like a sore thumb (well, like a
white line in a bunch of blue lines). I removed that line and the error
went away. The nice thing about GOB is that theres less "automagical
substitution" like in GObject, and more expressive syntax.

> [ incidentally we're trying to keep
> HEAD always building, and always working, always ].

Perhaps we'll have to adopt the old Bonobo policy that developers should
only use tarball releases ;-)

But seriously, HEAD gnome-vfs is *very* unstable right now. That'll
settle down in a few weeks, hopefully much sooner, but till then the
branch is probably the right place to live :(
> 
> 	Anyway, I'd really, really encourage you guys to explain what's up, and
> why you're going this way, what the advantages of gob are here, and how
> we can help make the other sensible ways of writing gobjects more
> attractive to you.

"I don't know gob" isn't really an argument against GOB that I'll
accept. Its really not hard to learn. I'm aware that theres a lot of
fear and antagonism directed towards gob by much of the community, but
technical xenophoboa isn't going to stop us adopting what we believe to
be a technically better solution thats easy for other people to work
with. As I said before, if you know GObject and you know Java you'll
understand GOB after 15 minutes with the man page and an example file.
> 
> 	Thanks, and sorry for forcing the issue - but it's better now than
> later,

I agree that we need to work this out now. I'm really interested in
hearing what arguments people have against gob. If there are good
reasons for not using it I'm sure you'll be able to convince Seth and I.

Ian