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.
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
