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

[Michael Meeks <michael ximian com>]

Hi Ian, 

On Wed, 2002-06-19 at 23:08, Ian McKellar wrote: 
> > 	Hmm. Have you looked at what Nautilus does with
> > GNOME_CLASS_BOILERPLATE ? that and GNOME_CALL_PARENT...
> 
> I haven't looked at that stuff. Does it take care of signals and
> inheritance and stuff for us too?

	It takes care of inheritance somewhat trivially, you still have to
connect / override your methods manually, and you need to use: 

	GNOME_CALL_PARENT (G_OBJECT_CLASS, dispose, (object)); 

	For signals you still need to type a chunk of stuff. 

> > 	I can only believe that gob makes much sense, if you intend to
> > radically re-structure your API frequently 
... 
> 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.

	Well - I don't think you address my question. Clearly the use of gob is
laudable for prototyping, as you say - it frees you from the tiresome
burden of typing the same thing again and again :-) I have no issue with
that. My real question is - how does it help you once the API is created
and moderately stable [ perhaps down to altering a method or so every
week ] ? 

	So, I would very, very much like to encourage you to use gob [ if it's
what you like ] to prototype, and at the end of the day, when the API is
stabilizing switch to using pure C. 

	Of course - one argument against this might be that you don't want to
do the work; well of course, the work is a trivial autotools change, and
(of course) making the generated code readable, perhaps transferring any
comments that are lost - again I'm happy to do this work for you. 

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

	The C pre-processor is standard, the idl compiler is unavoidable, much
in the same way that glib-genmarshal is. Worse people struggle with both
of these applications, understanding them, getting them to build stuff,
getting -j4 builds to work with them, stale stamp files etc. etc. 

	Why add another problem ? simply because we have existing problems
doesn't mean we should add more.[1] 

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

	Good - so shall we do a developer poll and see whether people generally
think the use of gob makes code harder to read, less accessible, and
harder to maintain ? Ultimately it's the people that get to do the
maintenance that count here, who are they ? 

> I don't think (as
> you can see) that straight C is the best language for everything.

	Agreed. 

> 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

	At this point your argument ran out of steam ;-) 

> > [ 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 ;-)

	Yes I screwed up badly in the past, I'm sorry, really. I'm hoping not
to do it again. Seemingly some things never change though, people still
try to sneak unapproved rubbish into modules ;-> 

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

	Well - this is pretty much not what we are hoping to agree for Gnome
2.X development, and fairly unacceptable on that basis. I understand
that it was thought that all de-stabilizing development must be done on
a branch, and only merged when it was stable. Thus keeping HEAD building
and working at all times.

> "I don't know gob" isn't really an argument against GOB that I'll
> accept.

	It is a good argument. There are better, such as "other people don't
know GOB", or "having generated files in CVS is a minefield for loosing
bug fixes", or "I fundamentally disagree with writing new
pre-processors" ;-) or whatever. 

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

	There are worse arguments, like gob is an unstable, unproven technology
that is not in the platform, and could easily generate bad code that
could screw us horribly between minor point releases, could 
break the ABI by method re-ordering, etc. etc. NB. these are not
particularly good arguments, but I'm only asking you to bin it when
you're past prototyping.

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

	Who should be arguing, is it for inclusion, or exclusion ? I mean, this
is a really personal thing so one has to respect your choice in this -
but I can see no reason why you can't use gob to prototype, and then
switch to pure C when the interface is simple. 

	Anyway, I eagerly await your responses in terms of doing unstable
development away from HEAD and the use of gob.

	Regards,

		Michael.

[1] - this is like the "smoking cannabis is better than smoking tobacco
=> it must be a good thing" non-sequitur, [ and I smoke mature stilton,
herring, fish cakes, persil, anything ].

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

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers