gnustep-dev
[Top][All Lists]
Advanced

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

Re: Possible code simplification and optimisation


From: Leigh Smith
Subject: Re: Possible code simplification and optimisation
Date: Wed, 22 Oct 2003 12:09:16 -0400

| I could add these as private classes and use them internally in the
| base library
| or I could add them as public classes in the Additions part of the base
| library
| or I could change the existing NSLock/NSRecursiveLock classes so that
| they do the same sort of thing.
The 3rd solution seems great.
The only problem I can imagine is using NSxxLock in a non multithreaded
environnement but really want to lock the mutex but I can't imagine a reason now. Idon't know enough DO so I can't say if this new feature may hurt something (is it
possible to use NSxxLock between applicationswich communicate by DO ?).


I also agree adding extra functionality to NSLock would be preferable, since it really is only an optimization of existing functionality, not an entirely new class, although perhaps an argument could be made for it to be a subclass of NSLock. To my mind, if there is a need for locking in a non-multithreaded environment, that could be achieved with a GS only method such as -setLazyLocking: (BOOL) yesOrNo which would default to YES. Does this contravene some GS policy of disallowing GS specific methods to NS classes? I wouldn't think we have such a policy?
--
Leigh Smith
mailto:address@hidden
http://www.leighsmith.com





reply via email to

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