Subscribe to
NSLog(); Header Image


I really, really like Objective-C's [square brackets] method of markup (whatever you wanna call it). Some of the people in this OSNews article are bitching and whining, but odds are, in my experience, they've simply never done much work with Objective-C.

Which, I ask you, would you rather deal with:

someObject.createConnection(mySocket, 12163, 28800, myClient, NULL);


[someObject createConnectionToSocket:mySocket onPortNumber:12163
    atSpeed:28800 withClient:myClient andExtraHeaders:nil];

I know I've got a lot of Mac users reading this site, and so they may be partial to Objective-C, but can anyone honestly give me a good reason for liking the first over the latter? "Fear of the unknown or strange looking" does not count.

17 Responses to "Brackets"

  1. A shot in the dark:

    Easier to write the former than the latter?

    Easier to read the former, since more people are used to it?

  2. Some may consider the dot operator clearer than just a space, but I love the way in which Objective-C requires you to say the parameters name also. This makes functions so much more clear, and allows you to reuse the function call so much easier.

    I also like the brackets because they delimit the function, also making it so much clearer. I showed the objective-c syntax to my Windows die hard friend, and he loved it.

    True, they show a departure from standard object oriented programming syntax, but it is so much clearer. (I guess the standard syntax is a departure from Objective-C's, as it was derived from Smalltalk.)

  3. I hated brackets when I was trying to learn Smalltalk for class. Course, since the point of the course was "how to learn new languages" and not "how to program in Smalltalk," the prof said "Get Squeak, do project."

    Now that I've made an effort to learn Obj-C, I appreaciate the notation more. Took me a bit to fully grasp it because I was so used to . and ->, but I find it quite useful.

    Just gotta remember not to use brackets when I'm writing Java or C++...

  4. Umm, the first one it shorter? 🙂

    Another advantage to the Obj-C method is that all the parameters are documented as to what they are by careful choice of parameter names.

    I say this as a C++ programmer recently introduced to Obj-C.

  5. I love Smalltalk-style named parameters. They make is much easier to just read the code and understand what is happening.

    The problems with the first option are lessened in a modern IDE like Eclipse. You can just hover over the method call to see the method signature and associated documentation. Still, I prefer Smalltalk-style named parameters.

  6. The brackets are pretty easy to get used to. But the length of all the named parameters can get a little tiresome. It forces wrapping, which makes the code even less readable in my opinion.

    Anyway, in C++ you'd often have:

    someObject.createConnection(mySocket, kPortNumber, kSpeed, myClient);

    ...which is a little better. (Using constants, and the extraHeaders parameter has a default value of NULL.)

  7. If your coming to obj-c via c or c++, the [] syntax can be a tad confusing at first. Once you get the hang of it however, I do prefer it to the standard syntax.

  8. Party like it's May 23rd

    Complete: Coming home from town after having a few drinks at the Brit-Pop party thingy they did at Gromo...

  9. Overall, I like the Objective-C syntax better. But there are good arguments for the C-style syntax as well. Having the method name all in one chunk makes it easier to do auto-completion without compiler support. It's also better for find and replace. If you're really familiar with what the method does, a shorter name is better because there's less to read. You don't have to wrap as many lines, and you can fit more code on the screen at once.

    Also, the bracket syntax is harder to type and edit. If you're typing a chain of calls, you have to either count them ahead of time so that you know how many open brackets to type, or go back and add the open brackets later. With the dot syntax, you just add another dot and keep typing. Likewise, if you have an expression selected and want to use it as a receiver, you have to add text on both sides. Editor support, such as BBEdit's Balance command and Glossary, can help a lot. But I'd like to see an editor that's bracket-savvy in the way that Emacs is for Lisp (which uses lots of parens).

  10. The thing I really like about obj-C style methods is the fact that you can tell what a method is doing without having to go look at the headers.

    Assuming the formatting comes out looking right, this is how I like to write methods. It takes up more space, and is more typing, but as an amatuer programmer, I love the fact that the method call lets me know exactly whats going on. No need to look up the docs unless I need more details.

    [someObject createConnectionToSocket:mySocket





    Of course, its up to developers to write the methods such that parameters are well named, but I'm happy with how Cocoa methods are named. If I want to do something, sometimes I just guess a method and its parameters, and half the time the method I guessed actually exists! I think this works because the methods are very readable and very memorable, at the cost of some typing speed.

    Obj-C, especially used with Cocoa, is a very friendly and easy to use combination that I'm very happy with as a relatively new person to the development world.



  11. My vote goes to the square brackets because... well, because square brackets are just cool.

    If you have a nosey through some of the more hip-'n'-happenin' contemporary sociocultural journals, you'll see copious square brackets put in there to funkify the traditional parenthetical asides. It's a typographical aesthetics thing. Some hard masculine edges to put some brawny machismo into your soft, feminine serif body text. So get some balls into your code, and use square brackets.

    Oh, and curly brackets are soooo last millennium.

  12. As someone who is learning Obj-C [or trying to], I'll just say they are more than a little daunting. But from that simple comparison things became a little clearer. Now, if other areas of the language made a little more sense, I might be a lot more productive in the language!

  13. this notation (and the namedparameters: ) is easier to read in a source code.

    I get to prefere objective C instead of C++ notation.

  14. I like the Objective-C syntax, but - objectAtIndex: is grotesquely verbose compared to operator[](). On the other hand, if you're doing a lot of work on data structures, there's a good chance you're using iterators anyway...

  15. Cocoa Syntax

    Erik Barzeski recently wrote in his blog: "I really, really like Objective-C's [square brackets] method of markup (whatever you wanna call it)." Cocoa's syntax owns pretty much everything I've used. I have used VisualBASIC, realBASIC, C++, PHP, and Coc...

  16. "someObject.createConnection(mySocket, 12163, 28800, myClient, NULL);"

    That's a poor example of C++ useage. Any good developer will run away screaming from "magic numbers". Good practice is to name *all* variables and constants, thus mitigating the problem as stated. Having said that, I can see some limited utility in typing parameter names.

  17. With Obj-C style of function, it is self-explainable. You don't need to look up the header file to figure out what parameter is for what.

    However, if you should write opening bracket and closing bracket always. So, it makes you keep go back to the point where you passed, and place an open bracket. If the call is something like this, then it is worse.

    MyClass *aclass = [[MyClass alloc] init];

    You may just start to write after = like this : My Class alloc] (Ah! I forgot the opening bracket! Let's go back)

    [MyClass alloc] init] ( Ah! I forgot another one!

    It looks like stupid thing, but it happens!

    So.. I think the code sense should be extended to the point that it can solve this problem. If not, I prefer the C++.

Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.