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

[Owen Taylor <otaylor redhat com>]

Seth Nickell <snickell stanford edu> writes:

> > > 	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.
> 
> Elaborating on this point... Look at the average number of objects used
> in most C++ modules and compare them to even the most heavily
> object-using C+GObject modules. Writing GObjects with C is a real
> implementation impediment that affects the usage of objects in the real
> world, even for those of us who are familiar with it. I seriously trade
> off cost of implementing GObjects vs. "I know this is the better way to
> do things" every time I think about using a GObject. I don't like to
> make that tradeoff, and I consider it a serious design issue. Because
> implementing objects in GOB is (imo) much lower cost, I don't end up
> making that tradeoff. So in that sense I think GOBs contribution is
> substantial.

However, don't get carried aware here in any case; the cost of a
GObject is a lot more than a C++ object; probably still a lot
more than a Java, C#, or Python object. 

(Not entirely sure about Python, would have to be benchmarked.)

Cost here is:

 - Code size (just because gob generates the code doesn't mean 
   there isn't code)
 - Object creation time (GObject isn't great at this)
 - Per-object overhead (GObject is pretty good here, only 12 bytes)

Regards,
                                        Owen