Re: Dealloc Notification

[Helge Hess]

Gerrit Van Dyk wrote:
> >I do not think this is acceptable. Here is why: It breaks compatibility
>
> >with OpenStep.
> Well I am breaking compatibility with the Openstep Spec. The Openstep Spec
> also does not define EOF.

The problem is not that you are breaking OpenStep (let's say MacOSX)
compatibility of gstep-base but of GDL !!! Right now GDL works on top of
MacOSX Foundation, after your change it won't anymore (except you
provide the API in the extensions library for MacOSX/OPENSTEP Foundation
too).

BTW: the same problem already exists for the gstep-ui, which is very sad
IMHO.

> Well we could keep the methods private between Foundation and
> the DB Library, I just thought that other uses for this would be handy as
> well.

It is handy for other stuff as well. But I would not support a GDL which
doesn't run on any Foundation.
I see no point in increasing the incompatibilities between the various
Foundation Objective-C implementations. Everyone is going to rewrite,
rewrite, rewrite all the time.

BTW2: this is the point of gstep-make library-combos ! Just recompile
GDL in a different combo (eg nx-nx or gnu-lf).

[memory footprint]
> Yes, it will increase the size by at least 1 byte per object. Another
> alternative is to use hashtables as per my previous email on the subject.

Hashtables would heavily increase the CPU usage for *any* object. Given
that deallocation is a pretty common method call, I would expect a
*significant* slowdown from that.

> >What you can do is go through the uniquing table from time to time and
> >see which objects have a retainCount of 1 and remove that. This does --
> >of cause -- not work with circular structures where each object is
> >uniqued.
^^^ Sounds like a very good suggestion to me !! (the problem is, that
GDL possibly has multiple caches, therefore a RC bigger than 1).
BTW: If I'm not mistaken GDL already can use the RC-based
GarbageCollector provided by FoundationExt.

> I think this a very bad idea. If I load lots and lots of objects I must
> iterate through all of these every time I want to check the uniquing tables.
> Why don't use a cleaner more OO approach? GNUstep belongs to us the
> developers, why create a lot of overhead if it is not neccesary. Private
> methods can do the trick, there is no specification on the use of private
> methods or are there?

Private API is, like the name implies, private to a framework/library.
GDL and gstep-base are totally separate frameworks to me. It doesn't
make sense to me to break GDL OpenStep compatibility just because of
*one* small inconvenience (which can be easily solved by subclassing all
DB objects from a single EOObject class !)

Greetings
  Helge
-- 
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises