GObject in GC implementation Plan

[Josh Sled]

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
- anyone is insisting to use QOF (in its current form)
- anyone does not want to migrate to GObject features

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

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070413/0808ec50/attachment-0001.bin