GObject in GC implementation Plan

[Daniel Espinosa]

2007/4/13, Josh Sled <jsled at asynchronous.org>:
> On Thu, 2007-04-12 at 17:42 -0500, Daniel Espinosa wrote:
> > 2007/4/12, David Hampton <gnucash at love2code.net>:
> > > On Thu, 2007-04-12 at 14:06 -0500, Daniel Espinosa wrote:
> > > > I can understand why you feel that; the reason is that I don't think
> > > > that convert QOF to GObject will be a good idea because its
> > > > implementation doesn't allow it, you'll never have a full GObject
> > > > system if you insist to use QOF.
> > >
> > > You keep making that statement, but you haven't explained what you mean
> > > by it.  Why can't we eventually migrate to a full GObject, what will be
> > > missing, and what will that mean to the project?  Please either explain
> > > yourself, or stop spreading what (at this point) I can only call FUD.
> > >
> > > David
> >
> > I don't want to create FUD, sorry. But you're right, I need to explain
> > in more details:
>
> I will point out that nothing you said or the responses you've received
> indicate that:
>
> - gnucash can never have a full GObject system

My point is QOF not GC.

> - anyone is insisting to use QOF (in its current form)

My point is the work to make QOF to be *FULL* GObject, and try to find
ways to speedup the migration.

> - anyone does not want to migrate to GObject features

I know.

>
> The issue has always been one of timing and planning, that the changes
> are made as a set of small, stable, understandable, auditable changes.
>

That's my objective, try to do the less work and try not to
re-implement the actual QOF way.

I insist to wrap QOF and step by step migrate QOF into a new pure
GObject implementation (move the code from QOF to the new)



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)