14

I'm reading a book about Smalltalk (Charmond Liu's Smalltalk, Objects and Design). He talks about how messages work in Smalltalk using a HomeBudget object as an example of how to send a single message with multiple parameters:

HomeBudget spend: 229 on: 'VCR'

Objective-C uses a lot of the ideas from Smalltalk, such as messaging objects and colons for parameters, but always encloses a message send in square brackets. The same call would be:

[homeBudget spend:229 on:@"VCR"];

Why does Objective-C use square brackets (instead of leaving messages bare like Smalltalk)? Is it required syntax because of the fact that it's C-based? Is it a stylistic choice? Does it offer more choice in what you can express? Is there another reason?

nevan king
  • 112,709
  • 45
  • 203
  • 241
  • 7
    from a parsing perspective, I suspect it has to do with playing friendly within C's grammar. – mah May 18 '14 at 15:52
  • 5
    @mah And, in fact, Objective-C started out as a custom C pre-processor + runtime. The pre-processor spewed straight C code that called into the runtime at method call sites and classes were basically glorified C structures (still are, really). – bbum May 18 '14 at 18:31
  • Similar curiosity from the opposite direction: [Why must the last part of an ObjC method name take an argument when there is more than one part?](http://stackoverflow.com/q/4479967) – jscs May 18 '14 at 19:00
  • 3
    What bbum says. It also helps that the Smalltalk syntax is kinda ambiguous when you make nested calls, so often you had to enclose method calls in brackets anyway, e.g. ((Class foo: 15) bar: 7) so for practical purposes, it actually turns out Smalltalk needed brackets, too. – uliwitness May 18 '14 at 19:05
  • 1
    Mostly, I suspect, it made building the Objective-C preprocessor a lot easier. Less C syntax had to be parsed and carefully analyzed to recognize a "message" and replace it with the equivalent C code. Without the brackets the preprocessor would, eg, have some ambiguity with label definitions. – Hot Licks May 18 '14 at 19:51
  • (Besides which, once your mind gets done flip-flopping, it's probably easier to read and understand Objective-C with the brackets rather than without. Without them message ops would not "pop out" as you read the text but would be lost in the "noise".) – Hot Licks May 18 '14 at 19:54

2 Answers2

12

I found an interview with Brad Cox that seems to hint that square brackets were for syntax:

DD: The square brackets are a distinctive part of Objective-C syntax. How did the square brackets come about and was this your doing?

BC: Yeah, that was me. Quite literally it was a search for something that wasn't taken. Curly braces were taken. Ordinary parentheses were taken. It was just a search for braces that wouldn't collide with something C used.

Tom Love also credits himself with the square brackets in Masterminds of Programming, but he seem to be saying that it was a stylistic choice:

I often refer to myself as the guy responsible for the square brackets in Objective-C, because Brad and I had a long conversation about. Do we have a C syntax that is consistently C, or do we create a hybrid language where I describe it as “the square bracket is a gear shift into the object land”? Our view was that if you had a hybrid language, you could build a set of foundation classes so that at some point most of the work is actually done inside the square brackets. This allows a lot of details to be hidden from a typical application programmer.

The square brackets are an indication of a message sent in Objective-C. The original idea was that once you built up a set of libraries of classes, then you’re going to spend most of your time actually operating inside the square brackets, so you’re really doing object-oriented programming using an underlying framework of objects that were developed in the hybrid language, which was a combination of procedural and object-oriented language. Then as you began to build up libraries of functionality, there’s less and less requirement to drop into the procedural world and you could stay within the square brackets. It was a deliberate decision to design a language that essentially had two levels— once you had built up enough capability, you could operate at the higher level. I actually think that’s one of the reasons. Had we chosen a very C-like syntax, I’m not sure anybody would know the name of the language anymore and it wouldn’t likely still be in use anywhere.

Community
  • 1
  • 1
nevan king
  • 112,709
  • 45
  • 203
  • 241
7

Objective-C is a strict superset of "C" and as such all additions were required not to alter the "C" language. That all "C" programs were also valid Objective-C programs.

C++ OTHO did make changes to the "C" language such that not all valid "C" programs will compile with a C++ compiler, are not also valid C++ programs.

So it was necessary to find symbols that were not used in "C" or at least not used in a conflicting context. Thus a lot of usage of "@" in Objective-C. In other cases to add symbols in order to disambiguate from "C".

zaph
  • 111,848
  • 21
  • 189
  • 228
  • Anything with an @ in front of it is a compiler directive, not necessarily a language feature. – CodaFi May 18 '14 at 17:30
  • @CodaFi Are you mixing up preprocessor directives (preceded by a #) here? The term "language feature" is vague enough that it can certainly cover *anything* that is part of ObjC (or C++, or whatever language you're talking about). – uliwitness May 18 '14 at 19:02
  • Meh, pedantry. `@-directives` indicate the compiler needs to perform some analysis more than simple preprocessor stuff. For instance, `@autoreleasepool` directives potentially expand to objc_autoreleasepool[push/pop], and @interface directives determine the size of the object and it's metaclass information in the object file by iVar declarations. `@property` declarations generate setters and getters with potentially nontrivial lifetimes. It's all possible to do by hand, we just don't because of the directives. – CodaFi May 18 '14 at 19:17