discuss-gnustep
[Top][All Lists]
Advanced

[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


reply via email to

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