Uncle Mac takes a cup of cold cocoa?
(null)/(null)/(null) (null) | Cocoa
Someone emailed me a link to this blog post today.
http://www.regdeveloper.co.uk/2006/12/29/grumpy_old_man_on_cocoa/
Now, before I start. Fair play to the guy, he's obviously new to Mac development (so welcome) and he's trying to write something and I can't knock him for that.
What I am somewhat nonplussed about is that he's decided to write a fairly damning blog post about the Cocoa frameworks and the XCode tools without really appearing to have taken the trouble to understand some of the basics.
So, in the hope that he (or you) finds some of this useful, I'd like to address some of his criticisms and comments.
Firstly, he starts by stating that "Cocoa objects don’t actually have properties" but then, somewhat confusingly adds, "Of course, we Delphi and C# developers understand that a property is usually just syntactic sugar-coating around a method call, right?"
Ok, I can see where you're coming from, us Java/Objective C developers also understand that. The 'syntatcic sugar coating' as he puts it is coming in Objective C 2.0, but really it's not an issue (at least for me). Follow the same rules as you would for any other language (including C#) i.e. writing getters and setters and you'll be ok and you'll also get the many 'for free' benefits of Key-Value Coding.
One such benefit is the ability to use Cocoa Bindings. I suspect that the author wasn't aware of Bindings (despite "[reading] three Cocoa programming books"). But really, using them would have solved a lot of his problems (writing array controllers, sorting columns in a table)
Plus, using Bindings you get a load of doohickeys that you can tick in the Inspector which look a whole lot like those things he was just moaning that there weren't any of (I won't call them properties, but I'm thinking of tick boxes with descriptions like 'Allows Editing Multiple Values' and so on).
"Imagine being able to drop a pushbutton control onto a form, double-click it and – bang! – there you are in the code editor, with an insertion caret inside your event handler." Nooooooo! I can imagine this. I've seen it, in Visual Basic and C#. I've also seen 'event handlers' performing most of the application logic.
Don't like it.
Imagine instead, a proper OO approach where you can assign selectors dynamically at runtime, use delegates to modify the behavior of the UI, send messages to any object willing to listen to them and retain the context of where they've come from. Like it or not, the UI is kind of separate from the rest of your code if you're using the Model, View, Controller pattern which is kind of enforced by the Cocoa approach (as well as other frameworks such as Rails) and is generally considered a good thing™
The other good thing™ about it is that, as sometimes happens, I can send just a .NIB file away to be localized or redesigned.
But seriously, if the VB.net/C# code/form designers are so good why are they all being replaced with WPF? Come on, they suck, really.
Oh, and I'm no Microsoft Hater :)
"But I really think that if the average Cocoa programmer spent some time with Delphi, s/he’d be totally blown away" I've spent some time with a Delphi developer, does that count?
http://www.regdeveloper.co.uk/2006/12/29/grumpy_old_man_on_cocoa/
Now, before I start. Fair play to the guy, he's obviously new to Mac development (so welcome) and he's trying to write something and I can't knock him for that.
What I am somewhat nonplussed about is that he's decided to write a fairly damning blog post about the Cocoa frameworks and the XCode tools without really appearing to have taken the trouble to understand some of the basics.
So, in the hope that he (or you) finds some of this useful, I'd like to address some of his criticisms and comments.
Firstly, he starts by stating that "Cocoa objects don’t actually have properties" but then, somewhat confusingly adds, "Of course, we Delphi and C# developers understand that a property is usually just syntactic sugar-coating around a method call, right?"
Ok, I can see where you're coming from, us Java/Objective C developers also understand that. The 'syntatcic sugar coating' as he puts it is coming in Objective C 2.0, but really it's not an issue (at least for me). Follow the same rules as you would for any other language (including C#) i.e. writing getters and setters and you'll be ok and you'll also get the many 'for free' benefits of Key-Value Coding.
One such benefit is the ability to use Cocoa Bindings. I suspect that the author wasn't aware of Bindings (despite "[reading] three Cocoa programming books"). But really, using them would have solved a lot of his problems (writing array controllers, sorting columns in a table)
Plus, using Bindings you get a load of doohickeys that you can tick in the Inspector which look a whole lot like those things he was just moaning that there weren't any of (I won't call them properties, but I'm thinking of tick boxes with descriptions like 'Allows Editing Multiple Values' and so on).
"Imagine being able to drop a pushbutton control onto a form, double-click it and – bang! – there you are in the code editor, with an insertion caret inside your event handler." Nooooooo! I can imagine this. I've seen it, in Visual Basic and C#. I've also seen 'event handlers' performing most of the application logic.
Don't like it.
Imagine instead, a proper OO approach where you can assign selectors dynamically at runtime, use delegates to modify the behavior of the UI, send messages to any object willing to listen to them and retain the context of where they've come from. Like it or not, the UI is kind of separate from the rest of your code if you're using the Model, View, Controller pattern which is kind of enforced by the Cocoa approach (as well as other frameworks such as Rails) and is generally considered a good thing™
The other good thing™ about it is that, as sometimes happens, I can send just a .NIB file away to be localized or redesigned.
But seriously, if the VB.net/C# code/form designers are so good why are they all being replaced with WPF? Come on, they suck, really.
Oh, and I'm no Microsoft Hater :)
"But I really think that if the average Cocoa programmer spent some time with Delphi, s/he’d be totally blown away" I've spent some time with a Delphi developer, does that count?
|