6 ms·

Honestly I always considered Objective-C to be one of Apple's secret weapon. Both higher and lower level then Java. Objective-C stays closer to the spirit of Sm

Honestly I always considered Objective-C to be one of Apple's secret weapon. Both higher and lower level then Java. Objective-C stays closer to the spirit of Smalltalk yet presents no hoop jumping when you need the performance of C. That, and Cocoa was not designed by morons - protocols and delegation, not inheritance, rightfully rule the day.

seanalltogether 16y ago
I'll agree with you on the protocols but not on the delegation. In fact apples engineers are all over the place on applying delegation and event handling. Some components have up to 3 different ways of handling callbacks - delegation, events, and notifications. Delegates are fine when you demand a 1 to 1 handshake, but they shouldn't be used for general callbacks.
- swannodette 16y ago
  Do you have a specific case in mind?
  - seanalltogether 16y ago
    UITextField is a good example - http://developer.apple.com/library/ios/#documentation/uikit/reference/UITextField_Class/Reference/UITextField.html http://developer.apple.com/library/ios/#documentation/uikit/... There are 7 delegate callbacks, 2 of which are voids so they're not really delegation methods. There is also a large list of UIControlEvents also sent around value change and touch events. Lastly 3 NSNotifications can also be dispatched by this object when data changes. Some of the list components are equally bad. The rule of thumb for ideal delegate vs event models is this. If you need a value returned, it should be a delegate method - (UIView )viewForZoomingInScrollView:(UIScrollView )scrollView but if a callback returns no data, it should not be a delegate but rather an event - (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView there is no reason for a void method to only allow for one listener and it's bad design.
- adamjernst 16y ago
  Agreed, but blocks are going to solve a lot of this. (In a really nice, clean way, to boot.)
  - jbrennan 16y ago
    Agreed, for the most part. Having closures in the language can really take away the repetitiveness of writing delegate protocols and conforming to them. I wonder if they will full absolve the need for delegates?
- catch23 16y ago
  delegates do make it a ton easier to write performant non-blocking code. It's almost like writing code for nodejs in a way, except without the deeply, deeply nested function calls.
  - swannodette 16y ago
    Makes you wonder why the Node.js folks don't get their act together and just adopt the paradigm.
Stormbringer 16y ago
If you've already committed to having a good OO design, then Inheritance is a brilliant tool for handling special cases.
- jonhendry 16y ago
  Yeah, it's useful. The thing is that other OO frameworks tended to go nuts with inheritance, building deep hierarchies.
aufreak3 16y ago
Protocols and delegation are only consequences of the true difference between Objective-C and the Java/C# mindset - which is that messages between objects are independent of the objects that send and receive them. In other words, messages are independent of the actual function call they cause in the end. So you can store, forward and broadcast messages, delay invocations, change invocation targets (classes, not just objects) on the fly etc. In yet more words, "late binding".
- fleitz 16y ago
  This was only true up until C# 4.0, C# now has dynamic (late) binding. Not sure how much of a PITA dynamic invocation is in Java.
  - arethuza 16y ago
    Which is nice except that Visual Studio 2010 seems to be a unreliable pig of an application. Which is a shame as I really rather like Visual Studio 2008.
_3u10 16y ago
I prefer to think of it more as "this language has all the memory safety of C combined with all the blazing speed of Smalltalk." I'm trying to like Objective-C but I don't. It feels like coding simultaneously in two different languages and you're never quite sure which one will be less painful to use. It makes you write statically typed code, but you still can't figure out what methods a class has in the IDE. On top of that half of a protocol usually doesn't need to be implemented but you have no idea which parts, and the IDE again can't just fill it out for you. I find I spend more time looking through documentation and copying interface signatures than coding. It has some kind of 'automatic memory management' but it seems barely better than that of C. On top of that if you get a compiler error it usually points you to a piece of code that has nothing to do with the actual error. I'm sure Objective-C was impressive in 1986, just like Java was in 1994, but it's 2010.
- chime 16y ago
  > you still can't figure out what methods a class has in the IDE. Maybe I don't understand what you mean but isn't that just an XCode auto-completion feature? Do you mean you can't see which methods belong to the class and which are inherited? > It has some kind of 'automatic memory management' Initially I was not too impressed by the alloc/retain/release/autorelease parts of Obj-C but now that I grok the concept well, I think it's awesome. I'm only coding for iOS devices but my understanding is that for OSX, there is a stable GC system. On iOS, you manage the memory yourself. I would have liked to not worry about memory at all but it's not a big deal after all. If you alloc/copy something, make sure you release it.
  - fleitz 16y ago
    I mean the intellisense (autocomplete + docs + method signature) in xcode blows chunks compared to Visual Studio or even Eclipse. Lots of things individually in Obj-C/Xcode are minor annoyances, but when you add them all together it's a very annoying toolchain. Comparing the UI/Polish in Apple products to Microsoft products, I figured that XCode would be one of the best dev environments ever. I think it's one of the worst. It's not that any of the issues are insurmountable, I'd just rather not deal with them.
deleted 16y ago
[deleted]
smackay 16y ago
Adding messaging to C to create Objective-C must be one of the most elegant language hacks ever. Brad Cox and Stepstone deserve all the credit not Apple (NeXT).
- jonhendry 16y ago
  Cox and Stepstone's Objective-C was pretty primitive. NeXT added a lot. Protocols, Categories, etc are from NeXT.

seanalltogether 16y ago

I'll agree with you on the protocols but not on the delegation. In fact apples engineers are all over the place on applying delegation and event handling. Some components have up to 3 different ways of handling callbacks - delegation, events, and notifications. Delegates are fine when you demand a 1 to 1 handshake, but they shouldn't be used for general callbacks.

swannodette 16y ago
Do you have a specific case in mind?
- seanalltogether 16y ago
  UITextField is a good example - http://developer.apple.com/library/ios/#documentation/uikit/reference/UITextField_Class/Reference/UITextField.html http://developer.apple.com/library/ios/#documentation/uikit/... There are 7 delegate callbacks, 2 of which are voids so they're not really delegation methods. There is also a large list of UIControlEvents also sent around value change and touch events. Lastly 3 NSNotifications can also be dispatched by this object when data changes. Some of the list components are equally bad. The rule of thumb for ideal delegate vs event models is this. If you need a value returned, it should be a delegate method - (UIView )viewForZoomingInScrollView:(UIScrollView )scrollView but if a callback returns no data, it should not be a delegate but rather an event - (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView there is no reason for a void method to only allow for one listener and it's bad design.
adamjernst 16y ago
Agreed, but blocks are going to solve a lot of this. (In a really nice, clean way, to boot.)
- jbrennan 16y ago
  Agreed, for the most part. Having closures in the language can really take away the repetitiveness of writing delegate protocols and conforming to them. I wonder if they will full absolve the need for delegates?
catch23 16y ago
delegates do make it a ton easier to write performant non-blocking code. It's almost like writing code for nodejs in a way, except without the deeply, deeply nested function calls.
- swannodette 16y ago
  Makes you wonder why the Node.js folks don't get their act together and just adopt the paradigm.

Stormbringer 16y ago

If you've already committed to having a good OO design, then Inheritance is a brilliant tool for handling special cases.

jonhendry 16y ago
Yeah, it's useful. The thing is that other OO frameworks tended to go nuts with inheritance, building deep hierarchies.

aufreak3 16y ago

Protocols and delegation are only consequences of the true difference between Objective-C and the Java/C# mindset - which is that messages between objects are independent of the objects that send and receive them. In other words, messages are independent of the actual function call they cause in the end. So you can store, forward and broadcast messages, delay invocations, change invocation targets (classes, not just objects) on the fly etc. In yet more words, "late binding".

fleitz 16y ago
This was only true up until C# 4.0, C# now has dynamic (late) binding. Not sure how much of a PITA dynamic invocation is in Java.
- arethuza 16y ago
  Which is nice except that Visual Studio 2010 seems to be a unreliable pig of an application. Which is a shame as I really rather like Visual Studio 2008.

_3u10 16y ago

I prefer to think of it more as "this language has all the memory safety of C combined with all the blazing speed of Smalltalk." I'm trying to like Objective-C but I don't. It feels like coding simultaneously in two different languages and you're never quite sure which one will be less painful to use. It makes you write statically typed code, but you still can't figure out what methods a class has in the IDE. On top of that half of a protocol usually doesn't need to be implemented but you have no idea which parts, and the IDE again can't just fill it out for you. I find I spend more time looking through documentation and copying interface signatures than coding. It has some kind of 'automatic memory management' but it seems barely better than that of C. On top of that if you get a compiler error it usually points you to a piece of code that has nothing to do with the actual error. I'm sure Objective-C was impressive in 1986, just like Java was in 1994, but it's 2010.

chime 16y ago
> you still can't figure out what methods a class has in the IDE. Maybe I don't understand what you mean but isn't that just an XCode auto-completion feature? Do you mean you can't see which methods belong to the class and which are inherited? > It has some kind of 'automatic memory management' Initially I was not too impressed by the alloc/retain/release/autorelease parts of Obj-C but now that I grok the concept well, I think it's awesome. I'm only coding for iOS devices but my understanding is that for OSX, there is a stable GC system. On iOS, you manage the memory yourself. I would have liked to not worry about memory at all but it's not a big deal after all. If you alloc/copy something, make sure you release it.
- fleitz 16y ago
  I mean the intellisense (autocomplete + docs + method signature) in xcode blows chunks compared to Visual Studio or even Eclipse. Lots of things individually in Obj-C/Xcode are minor annoyances, but when you add them all together it's a very annoying toolchain. Comparing the UI/Polish in Apple products to Microsoft products, I figured that XCode would be one of the best dev environments ever. I think it's one of the worst. It's not that any of the issues are insurmountable, I'd just rather not deal with them.

deleted 16y ago

[deleted]

smackay 16y ago

Adding messaging to C to create Objective-C must be one of the most elegant language hacks ever. Brad Cox and Stepstone deserve all the credit not Apple (NeXT).

jonhendry 16y ago
Cox and Stepstone's Objective-C was pretty primitive. NeXT added a lot. Protocols, Categories, etc are from NeXT.