Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Collection Creation
While most of the new changes fall into the category of "actively bad," one is merely useless. You can now create NSDictionary and NSArray instances with some special shorthand syntax:
NSArray *a = @[ @"foo", @"bar" ];
NSDictionary *dictionary = @{@123 : @123.4 ,
@"date" : [NSDate date] };
Why is this useless? For one thing, it simply duplicates the functionality of a pair of macros that we've been using for many years: D() and A() respectively call +dictionaryWithObjectAndKeys: and +arrayWithObjects: and add a nil terminator.
The other reason, of course, is mutability. When we added these macros in Étoilé Foundation, we discovered within a few months that it was very common to want to use them for mutable collections. When you create a collection from a few literals like this, sometimes you really want a custom class and are too lazy to implement one, but just about as often you either want to replace or modify a few default values. In this case, the new syntax gives no benefit. I suppose you could write this:
[[@[ a, b ] mutableCopy] autorelease]
instead of this:
[NSMutableArray arrayWithObjects: a, b, nil]
But would you? Is it really easier to read?
Collection Subscripting
Collection subscripting was intentionally omitted from Objective-C at the start. Like operator overloading, it has the problem of hiding the complexity of an operation.
After the dot-property notation debacle, we might have hoped that Apple developers would have learned from their mistake and remembered one of the most important rules of the design of Objective-C: New syntax requires new semantics. In fact, in Objective-C++ mode, it's trivial to wrap Objective-C collections in C++ classes and access them via an overloaded operator. The fact that no one actually does it should be a hint that it's not a particularly valuable addition.
As with the dot notation, code is now less clear. Previously, if you saw this:
a[b];
then you knew the following (unless you were in Objective-C++ mode):
- a is a C array.
- b is an integer type.
- This operation is a simple pointer arithmetic expression that will compile down to a couple of instructions.
Now, you know none of these things. It may still be cheap, but indexed Objective-C containers don't make any such guarantees. In fact, if b is an object rather than an integer, it will call a different accessor. Here it gets even more fun. We already had two well-known methods for accessing collections indexed by objects: The -objectForKey: method is specific to NSDictionary, while -valueForKey: is part of key-value coding and is defined on a variety of things. Now we have a third: -objectForKeyedSubscript: is used by the subscript notation. It's not totally clear why this needs to be yet another one.
Overall
As I said in the Objective-C Phrasebook, the advantage of Objective-C is that it's a set of simple and elegant extensions to C, without overloaded syntax. It seems that Apple is intent on destroying this simplicity and making a language as baroque as C++.
I thought that my opinion might be in the minority, but so far the only positive opinions I've heard about the new syntax are from people who work at Apple. Every other Objective-C developer I've asked has felt either negative or indifferent. One summed it up very well: "It seems that Apple has forgotten what it is that makes Objective-C a great language." It's pretty clear that no one actually evaluated what the gains might be before making these changes to the language.