Re: Remove GCObject, GCArray, GCDictionary from base?

[Matt Rice]

--- David Ayers <address@hidden> wrote:

> Richard Frith-Macdonald schrieb:
> > As far as I know, the garbage collecting classes
> in the base  additions
> > library are used only in gdl2.
> > It would seem to make sense to move themover into
> gdl2 rather than  the
> > base additions library.
> > What do you think?
> 
> Personally I had hoped to remove the use of them in
> GDL2, but it was
> never a high priority.  In fact I don't even really
> know if they
> actually fix the retain cycle issue that they are
> intended to solve in
> our EOModels.  I never wrote any tests as most GDL2
> applications
> wouldn't even notice the difference as they don't
> add / remove models.
> 
> The main application I would worry about here is
> GDL2's DBModeler.  It
> would be great if "we" (read Matt ;-) ) can work out
> a way not to need
> them at all.  Personally I wouldn't mind of they
> were moved into GDL2 in
> the meantime as long as GDL2 didn't make them
> public.
> 
> Alternatively we could create a 'BaseUtilities'
> NATIVE_LIBRARY project
> and have GDL2 depend on that in the meantime.  Then
> people who currently
> may still be using these classes have a migration
> option.
> 

ok, so EOAccess/* should be done, 
the GCObject is still in use in EOControl's
EOFault/EOFaultHandler/EOMKKDInitializer classes

I don't really know enough about these classes to go
monkeying around with them, but if nobody volunteers i
guess i can figure 'em out.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com