Re: [GNOME VFS] gob inside gnome-vfs ...
Seth Nickell <[email protected]>
| Newsgroups | gmane.comp.gnome.vfs |
|---|---|
| Message-ID | <1024526552.23884.21.camel@beauty> |
> > 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. On a side note, wrt to maintenance, GOB both helps and hurts. Jody has pointed out that GOB has some detrimental effects on maintenance because it adds one more layer in the dependency stack that could break. If people are really worried about GOB changing and CVS HEAD being broken for a certain amount of time before one of the maintainers (both of whom prefer GOB in terms of maintainability) I'd be willing to disable automatic running of gob at compile time (even for CVS checkouts) and just run it manually myself whenever the .gob files change, and then check the output files straight into CVS. I think its ugly, but it might allay people's concerns that concerns with GOB's "maintainability" will have a negative impact on them. I would *much rather* use a language with object support than GOB (even, say, C++), but since GnomeVFS is a platform library that's not really an option. -Seth _______________________________________________ gnome-vfs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gnome-vfs