| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Thomas McQuitty wrote:_______________________________________________
| However, I still look at some of the code in Objective-C and compare
| it to C++ and wonder why the function calls in Objective C are so dang
| long. I don't know of another language where you specify the
| function's variable along with the passing variable.. :)
Chris Hanson wrote:
| (a) They aren't function calls, they're message sends. The method
| invocation that they result in is looked up dynamically at run time.
It looks like a duck, it quacks like a duck. You invoke it, you hand it something to crunch, it returns a value. It has a distinctive syntax, but it's still a function call. (C++ and Java both offer functions calls that are looked up dynamically, so that's not a distinction.) As long as you remember that the call is dispatched dynamically, it doesn't really matter what you call the control structure. (The distinction between "method" and "member function" is equally meaningless. While using each language's preferred terminology is recommended, mix-and-match isn't really going to cause misunderstanding.)
| (b) Functions aren't passed variables, they're passed parameters. Same
| with message sends. Passing the parameter names is very useful, it
| really does lead to much more self-documenting code than most other
| languages.
As long as we're being pedantic, what's being passed are indeed variables (or, more accurately, expressions or values); parameters are what the passed values are passed *into*. That is, the things in the call are variables (or "arguments" if you want to be extra picky); the things in the function body are parameters. (Or vice versa. There's no standard--or even concensus--on what's an argument and what's a parameter. Most people use them interchangably.)
| (c) The keyword-argument message send syntax comes from Smalltalk.
| Common Lisp also supports optional keyword arguments.
Among other languages. (It's been proposed for C++; I don't recall whether the proposal got anywhere.)
And, to add a couple of points:
(d) It may help to regard all those keywords as just the name of the function, broken up into bite-sized pieces. There's not all that much difference between
target.performSelectorWithObject(selector, object);
and
[target performSelector: selector withObject: object];
except that the selector form has mixed the arguments in with the name. The names seem longer in Cocoa not because they're Objective-C, but simply because the Cocoa designers tended to choose verbose names, presumably in the interests of making things readable. It would have been quite possible to make the preceding function be
[target do: selector with: object]
which would have been considerably shorter, but perhaps less clear.
Also, Cocoa selector names tend to include the type of the passed value, so that a single class can have, for example, initWithObject:, initWithArray:, initWithGarbage:, and so on, where C++ would simply overload a single name based on the type of the argument. The need to make the overloading part of the selector name makes the names longer. And once argument types get included in some places, it's better to include them in all places, even those that don't strictly need it, so that all selectors follow a single naming convention.
(e) You can, for your own code, make things far more terse. For example,
- (id) doSomethingWith: (id) arg1 : (id) arg2 : (id) arg3
{
...
}
which would be called using
[target doSomethingWith: thing1 : thing2 : thing3];
reducing all the keywords but the first to mere colons. I wouldn't recommend this approach (making code readable has a lot of benefits), but it's quite possible. (It's probably best reserved for class-"private" methods.)
Glen Fisher
_______________________________________________
projectbuilder-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/projectbuilder-users
Do not post admin requests to the list. They will be ignored.
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.