Re: A question about static typing
Re: A question about static typing
- Subject: Re: A question about static typing
- From: Greg Titus <email@hidden>
- Date: Sat, 21 Jul 2001 10:30:20 -0700
On Saturday, July 21, 2001, at 09:34 AM, R. Tony Goold wrote:
>
> I've been working my way through "Learning Cocoa" and I can't figure
>
> out why the authors static type some places and not others.
>
>
Static typing is useful for catching some errors at compile time which
>
would be missed by simply using the id type, such as unsupported
>
methods. There are other times when static typing is impossible because
>
you don't know what type to expect. I would ask the question "why
>
didn't they use static typing here?"
One correction (or clarification really): an unsupported message is a
warning and not an error. The Objective-C compiler is built that way
because the programmer is (sometimes) smarter than the compiler and
calling a message on an object that it doesn't appear to support may be
exactly what the author of the program intended. Use of features like
forwarding often leads to these types of things, for instance.
The fact that so many potential problems are warnings instead of errors
in Obj-C points out why it is a really really bad idea to ignore
warnings or turn them off.
But to get back to the main point: yes, using static typing whenever you
know what kind of object you are expecting is good practice because then
you do get those compiler warnings that _usually_ mean you've done
something wrong.
>
It's probably also worth pointing out that books and magazines on
>
programming often sacrifice style for brevity. Object oriented
>
practices help to manage complexity, but there isn't much complexity in
>
a 10-20 line code snippet so "good practices" are only a minor
>
consideration. Unless we're talking about a book on software design!
Absolutely. Even books on software design can have bad examples for this
reason.
>
> They particularly like to static type outlets but I can't understand
>
> why outlets are especially error prone. It seems that static typing is
>
> less likely to help here than in the general case since one is more
>
> likely to,
>
> for example, send a button message to the wrong button than to send a
>
> textField message to a button.
>
>
As a very simple case, consider typos:
>
>
id button1;
>
NSButton* button2;
>
[button1 titel]; // Mistake not caught until execution
>
[button2 titel]; // Mistake caught during compilation
>
>
There are similar mistakes related to casting which can also be caught
>
during compilation by using static typing. I tend to think of the "id"
>
type as a "void*", something best used when there is no other choice.
>
Neither permit much in the way of compile time error checking.
Actually in this particular case you'd get a warning for both lines of
code. For button1 the compiler would warn you that it doesn't see a
'titel' method on ANY class. Again, you might know what you are doing
better than the compiler does, but it tries to be helpful just in case
it was a typo. :-)
>
Mind you, I learned Objective C only recently, after I'd been
>
programming in C++ for a while, so this may be more of a C++ oriented
>
philosophy. If I've missed something, maybe one of the ObjC gurus can
>
set me straight here.
Nope, everything you've said sounds good to me. The main difference
between Obj-C and a static language like C++ is that you need to be
aware that any static typing that you do is _advisory_ and not
neccesary. It's good documentation, and it can help the compiler warn
you about potential problems, but it does NOT effect code generation in
any way whatsoever.
So really the rule is a documentation rule: use static typing wherever
it makes your code easier to understand (for the compiler or for another
programmer looking at it) and use "id" wherever _that_ makes your code
easier to understand (because it emphasizes that this particular object
could be anything).
--Greg