Re: NSCalendarDate from plist
Re: NSCalendarDate from plist
- Subject: Re: NSCalendarDate from plist
- From: "Erik M. Buck" <email@hidden>
- Date: Mon, 26 Nov 2001 00:15:58 -0600
- Organization: EMB & Assocites Inc.
>
I'd still like to be using a language that could express this correctly,
>
though (although I'm not really a language lawyer). Using id for a
>
return type seems like sort of a sledgehammer approach...
>
Eiffel tried to get this right. There are legendary wars on the news groups
debating if Eiffel got it right or not. This is one of the hardest problems
with strong static compile-time type systems.
Using id is perfectly sensible and elegant in a weak dynamic run-time typed
language like Objective-C. Early versions of Objective-C ONLY had the id
type and great programs were written. Using static types in Objective-C
merely provides hints to the compiler. All object and message types are
dynamic and resolved at run-time no matter what you type in. Hell, the
ultimate receiver of a message may not even be in the same process as the
sender and there is no way at compile time to know one way or the other! It
is impossible for the compiler to verify or require type consistency in
messaging.
id is the light weight "feather" solution that is very elegant in a weak
dynamic run-time typed language.
Introducing all of the issues with covariant/contravariant type signatures
and ridged compile-time type checking is the heavy weight "sledgehammer"
approach.
Not everyone likes flexible languages like Smalltalk and Objective-C. That
is OK, but if you are using Objective-C, you should not complain about its
very deliberate features. Cocoa would not exist without them.