[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q's about GNUstep (-make & -base)
From: |
Michael Ash |
Subject: |
Re: Q's about GNUstep (-make & -base) |
Date: |
Sat, 14 Jun 2008 22:26:10 -0500 |
User-agent: |
tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE-p20 (i386)) |
David Chisnall <theraven@sucs.org> 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
Message not available