David Chisnall <[EMAIL PROTECTED]> wrote: > I agree. The fast enumeration pattern can easily be implemented using > C macros - it almost is in GCC, which just expands it into a few > simple calls. In ?toil? we have a FOREACH macro which uses iterators > and performs IMP caching on the -nextObject method. It's slightly > slower than the fast enumeration system, but it works without > modifying the collection objects and so works on things like the > Address Book collections (which Apple's fast enumeration doesn't, or, > at least, didn't when Leopard shipped).
Although the fact that NSEnumerator supports NSFastEnumeration makes this easier, since it's just one extra method call in the for loop. That's assuming these collections can return enumerators, anyway. If you really wanted to, you could implement NSFastEnumeration on NSObject in a default way which calls -objectEnumerator and then -nextObject repeatedly to solve this. Apple apparently didn't think it was worthwhile though. > I'm still in two minds about properties. They do save a bit of typing > when declaring set / get methods, and the ability to add instance > variables that are not visible outside the class is nice, but I am not > entirely sure they add anything that late-bound ivars don't. They're actually pretty much orthogonal to late-bound ivars. They exist in Apple's 32-bit runtime which doesn't have them, for example. The real benefit is simply in automatically managing getters and setters, and in allowing code to explicitly separate between methods that you call and properties that you set (even if they end up being the same in the end). I'm told that the addition of metadata to the properties, like copy or nonatomic, is a benefit in that it tells you more about the property than just the fact that it exists. I'm not totally sold on this, since I think those should often be internal implementation details rather than part of the public interface, but there you are. > That said, Apple seem to be encouraging people to use all of this > extra syntax, even when it isn't sensible, and so it's probably worth > supporting. I'm sure that supporting @property and the dot syntax for accessing them (which is not actually related language-wise) will help with code portability quite a bit in the future. -- Mike Ash Radio Free Earth Broadcasting from our climate-controlled studios deep inside the Moon _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
