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

[Michael Meeks <michael ximian com>]

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 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 ?

> 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.

> 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 :-)

	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.

	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 [ incidentally we're trying to keep
HEAD always building, and always working, always ].

	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.

	Thanks, and sorry for forcing the issue - but it's better now than
later,

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot