On 14 Jul 2009, at 09:15, Fred Kiefer wrote:
Gregory Casamento schrieb:
Author: gcasa
Date: Mon Jul 13 20:14:42 2009
New Revision: 28393
URL: http://svn.gna.org/viewcvs/gnustep?rev=28393&view=rev
Log:
* Headers/Foundation/Foundation.h
* Headers/Foundation/NSOperation.h
* Source/GNUmakefile
* Source/NSOperation.m: Initial implementation of NSOperation
class.
Added:
libs/base/trunk/Headers/Foundation/NSOperation.h
libs/base/trunk/Source/NSOperation.m
Modified:
libs/base/trunk/ChangeLog
libs/base/trunk/Headers/Foundation/Foundation.h
libs/base/trunk/Source/GNUmakefile
Hi Greg,
did you notice that Nikolaus Schaller has added a version of
NSOperation
to the latest mySTEP code as well? The class itself is less complete
than yours, but you might be interested in the subclass
NSInvocationOperation and as you know we may freely pick code out of
mySTEP and move it to GNUstep, as long as we reference Nikolaus as the
author.
Also a few other points ...
1. I have been looking into implementing NSOperation for a while, and
it's trickier than I initially thought. I had started writing code
using locks, but had come to the conclusion that this was a bad idea
as things would be too slow for using the class to be worthwhile. I
believe that David Chisnall said that Etoile has an implementation of
a thread-safe non-locking queue, and this would obviously be worth
looking at as a fast thread-safe list of operations appears essential
for decent performance of the operation queue.
2. We need to bracket the header file in the macros to say it's only
available from OSX5 onwards.
3. Before going further with actual implementation, we need to fix the
header files to avoid having instance variables (other than an opaque
pointer) visible in the public classes, so that changes to
implementation details won't break the ABI in future releases. I'm
doing that for all new classes in base. It would be nice to do it for
existing classes too, but obviously whenever we change the ivar layout
in existing classes we break ABI, which rather defeats the purpose
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev