bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: obsolete method and behavior adding


From: Richard Frith-Macdonald
Subject: Re: obsolete method and behavior adding
Date: Fri, 22 Mar 2002 13:47:35 +0000

On Friday, March 22, 2002, at 01:18 PM, Markus Hitter wrote:


Hello all,


here's a issue, I'm not too sure about.

In NSArray.m I see:

@implementation NSArray
...
+ (id) allocWithZone: (NSZone*)z {
  if (self == NSArrayClass) {
...
    } else {  // != NSArrayClass, e.g. GSArrayClass
      return NSAllocateObject(self, 0, z);
    }
}


In GSArray.m, something similar:

@interface GSArray : NSArray
...

@implementation GSArray
...
+ (id) allocWithZone: (NSZone*)zone
{
  GSArray       *array = NSAllocateObject(self, 0, zone);

  return array;
}


To all of my knowledge, the first implementation makes the second obsolete?

Well, yes ... the second implementation is just a tiny bit more efficient, but it's
not necessary and the efficiency gain is trivial.


The reason I came across such an issue is, on NeXT runtime behavior_class_add_class() makes major trouble. A possible conclusion might be, we have to get rid of behavior adding on NeXT runtime, at least in +initialize methods.

I think a better conclusion is that the NeXT runtime implementation should be fixed.

In all occurences of behavior_class_add_class(), some GS* class is involved. I'm trying to find out why all these GS* classes exist.

They are generally the concrete implementations of classes within a class cluster. They contain the code which actually does most of the work of the base library.

Is it OK to consider behavior adding as some sort of multiple inheritance trough the backdoor?

Pretty much. It's mostly used to let mutable classes inherit the methods of their
immutable counterparts.  The only workarounds for the lack of it are -
1. duplicate the code ... with all the obvious disadvantages for maintainability and code size. 2. put the shared code in a header file and include it into both the mutable and immutable class implementations. Basically the same as option 1 but a little neater.

PS. The bug mailing list is probably not the right place to discuss porting issues.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]