Forget the fact that we're not even talking about methods, really, we're talking about messages (a distinction I'm not going to make) and you refer to selectors like the one above as performAction:withTwoParameters:. Most people don't care anymore.
Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is basically 99% "Smalltalk in square brackets". Nobody complains that Smalltalk has a strange syntax, even small kids seem to use Squeak just fine.
in Python, or any language with named parameters. The syntactic differences are superficial. You don't even have to know about selectors and messages to understand the gist of what that invocation will do. "OMG, method parameters have a name" --well, big effin' deal.
Ever seen C++ (especially the recent standard)? Or the beast with 1000 features C# has become? Obj-C compared is leanness personified.
The ACTUAL source of complexity in programming in Objective-C is the huge Cocoa (et al) API. But a huge API, especially nicely documented as Cocoa is, and with such breadth and nice MVC design, is a GOOD THING.
This tightly-coupled codesign is unique to Objective-C. There are other languages that run on .Net, such as Iron Python. Lots of language use the JVM besides Java, like Clojure. Even Ruby and Rails are two distinct entities and projects. The only significant effort to use a different language with Cocoa/Cocoa Touch and the Objective-C runtime, Mac Ruby, was a project largely backed by Apple before they abandoned it.
Actually, there are several efforts besides MacRuby to use another language with the Objective-C runtime: Nu (Lisp like), F-script (Smalltalk like). But the main difference here is that the Objective-C runtime is a very simple runtime, not a full VM, so the comparison to CLR and Java is not that apt. For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5.
It's many things to many people. To beginners, its a friendly cub to play with. To enterprise coders its the beast of burden to carry things. To newbie web developers/existing c++ programmers its familiar face on a new road. It won't devour you unless you have a death wish.
withTwoParameters is actually part of the method signature. It's not a keyword identifier.
Sure, but it's not like that distinction is really important for the programmer. For most intends and purposes, he can just think of those as keyword identifiers
--or, better, as a kind of keyword identifiers that also have to be present whenever referring to the method.
> Sure, but it's not like that distinction is really important for the programmer. For most intends and purposes, he can just think of those as keyword identifiers
(I'll use lisp conventions, it's what I'm used to)
What you're saying is for coders, saying
(doit x y :withFloat 5 :key "string")
has no important distinctions with
[foo doit:x:y withFloat:5 key:"string"]
But keywords have defaults if they're missing. And furthermore you can have them in any order. So to implement the equivalent of the Lisp method above, I'd have to implement all of the following methods in Objective-C
For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5.
I can't agree with this. Jython and Rhino started in 1997. JRuby started in 2001. Those are all ports of fairly major languages, and all saw significant use before 2004.
The fact that he chose the fake method name performAction:withTwoParameters: betrays that he doesn't know what he's talking about. Under the Apple style guide you would describe the parameters next to the arguments in the method signature itself, and in this case would use something more like performActionWithParameter1:parameter2.
You do this so that you actually know what you're putting into the damn function. As soon as you've typed 'object per' Xcode's autocomplete will have filled out the rest of the entire function, complete with parameter descriptions and little empty bubbles with the expected argument class for you to tab over and type your arguments into. This is indispensable if you have a method with a large number of arguments.
Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is basically 99% "Smalltalk in square brackets". Nobody complains that Smalltalk has a strange syntax, even small kids seem to use Squeak just fine.
[object performAction: param1 withTwoParameters: param2]
not that different to:
object.performAction(self, param1, withTwoParameters=param2)
in Python, or any language with named parameters. The syntactic differences are superficial. You don't even have to know about selectors and messages to understand the gist of what that invocation will do. "OMG, method parameters have a name" --well, big effin' deal.
Ever seen C++ (especially the recent standard)? Or the beast with 1000 features C# has become? Obj-C compared is leanness personified.
The ACTUAL source of complexity in programming in Objective-C is the huge Cocoa (et al) API. But a huge API, especially nicely documented as Cocoa is, and with such breadth and nice MVC design, is a GOOD THING.
This tightly-coupled codesign is unique to Objective-C. There are other languages that run on .Net, such as Iron Python. Lots of language use the JVM besides Java, like Clojure. Even Ruby and Rails are two distinct entities and projects. The only significant effort to use a different language with Cocoa/Cocoa Touch and the Objective-C runtime, Mac Ruby, was a project largely backed by Apple before they abandoned it.
Actually, there are several efforts besides MacRuby to use another language with the Objective-C runtime: Nu (Lisp like), F-script (Smalltalk like). But the main difference here is that the Objective-C runtime is a very simple runtime, not a full VM, so the comparison to CLR and Java is not that apt. For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5.
In general, not that good of an article...