On Tuesday, August 20, 2002, at 04:15 PM, Alexander Malmberg wrote:
>> Thanks ... this should be fixed in CVS now. >> >> At the time when NSProxy was implemented, the behavior of many methods >> was >> undocumented. Now the MacOS-X documentation covers more methods, and >> makes >> it clear that -isKindOfClass: should be forwarded to the remote object >> (though >> -class apparently should not). >> >> Sorry it took a while, but I wanted to document NSProxy and correct the >> regression tests too. > > These changes broke distant objects (at least in some cases, notably > pasteboards). I tracked down the problem to the > 'RELEASE(node->value.obj);' in [NSConnection -removeProxy:]. This only > gets called when the object is being dealloced, so the additional > release here and the new -release implementation in NSProxy cause a > loop. Objects are not retained when they're added to _remoteProxies, so > I don't see why there should be a RELEASE here. Removing it fixes the > problems, so I've done that in cvs. Thanks ... sounds like the change exposed a minor bug. > Also, I think [NSObject -replacementObjectForPortCoder:] is broken, > although it doesn't seem to cause any problems. [self isKindOfClass: > proxyClass] doesn't make any sense; even if it is a proxyClass object, > it will forward the call and return NO anyway. Using -isProxy makes more > sense to me, but I haven't changed anything since it hasn't caused me > any problems. I've removed that code fragment ... it was intended to handle encoding of NSDistantObject, but that class overrides the method anyway - so the code in NSObject was redundant. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
