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

[Seth Nickell <snickell stanford edu>]

Michael,

The use of GOB simply isn't worth all this strife. The benefits or costs
of using or not using GOB are dramatically outweighed by the rise in
tension and arguments. So...compromise...

I plan to use GOB (on HEAD) until such time as I consider the most of
the object work done for GnomeVFS 2.2 (I'm planning for this to be less
than a month). At that point I will be willing to accept patches that
de-gobitize GnomeVFS[1]. I personally feel this is mildly detrimental to
maintenance, but the main benefit of GOB I am interested in is the
coding flexibility while the object interfaces are still in process. On
the anti-gob part, this means the GOB will only be in GnomeVFS for a
relatively short amount of time, and won't make it into any released
code (which should satisfy your main concerns).

Does that seem acceptable to everyone?

-Seth

On Thu, 2002-06-20 at 04:24, Michael Meeks wrote:
> 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
>