Re: To C++ users trying to use Cocoa
Re: To C++ users trying to use Cocoa
- Subject: Re: To C++ users trying to use Cocoa
- From: Ian Joyner <email@hidden>
- Date: Sun, 13 May 2007 13:33:50 +1000
I think there is a place for some counterpoint here.
On 13/05/2007, at 10:12 AM, Andy Lee wrote:
On May 12, 2007, at 8:01 PM, Erik Buck wrote:
In recent years, there has also been a modest rebellion against
"bondage and discipline" programming languages.
That is perhaps rather an extreme portrayal of languages with strong
typing. Perhaps it applies to languages where the typing mechanism is
not flexible enough, such as pure academic Pascal. Maybe C++ you
could also see in this role, but its attempt at introducing strong
typing into a low-level environment which still has so many problems
inherited from C is unsatisfying. The categorization of those who
have designed strong typing systems as pedagogic demagogues is
somewhat unfair – the whole approach comes from being able to write
provably correct programs detecting problems as early in the life-
cycle as possible.
The whole area of static type checking has progressed a long way in
the last 20 years, recognizing that early attempts were too
restrictive and putting the flexibility back in – that is you can
have your cake and eat it static typing with flexibility.
The idea of doing lots of unit tests are a good idea, however, it is
difficult to get complete coverage, whereas a typed language detects
all areas of potential error, so coverage is complete. I then don't
have to worry about writing a whole class of tests.
Along those lines, I found this article very interesting. I came
across it in Joel Spolsky's "The Best Software Writing I."
<http://www.mindview.net/WebLog/log-0025>
Interesting article. The basic problem, as shown, is with containers,
where you put things for later processing by iteration. It's the
pulling different types out of the collection and applying operations
to them where the problem occurs. This is where multiple inheritance
and genericity really help to make typing much more flexible.
In the example, I would make an abstract class Speaker, with the
operation speak. Thus any object that needs this behaviour inherits
from Speaker. Since speak must always be defined in subclasses,
Speaker is entirely abstract like a Java interface – however, there
is no need for this restriction, other classes may be abstract and
have mixes of defined and undefined operations. A container for
speakers could be defined as:
speakers: Collection [Speaker]
where the collection is constrained to only have objects which define
the speak operation in them:
speakers.next.speak
Now that's where the inflexibility occurs – suppose we really have no
knowledge of the objects that can be put in a collection? Type
systems can allow such cases:
things: Collection [id]
....
things.next.speak
must cause a compile-time error since we cannot guarantee that an
object typed id defines speak. A simple syntax addition will allow
the compile-time checking to let it pass to run time.
things.next.speak?
puts dynamism back in the language for those few cases where dynamism
helps. Of course, the '?' form of the call will be orders of
magnitude slower than the typed version, because the test must be
done at runtime. The question is, should '?' throw an exception, or
just ignore the fact that an object does not define speak. Perhaps a
further form:
things.next.speak!
says, throw an exception if the object does not implements speak,
whereas ? just does not apply the call.
Thus I think you can have static typing with the flexibility of
dynamism without throwing the baby out with the bathwater (sorry for
the cliched analogy!)
This became a puzzle to me: if strong static type checking is so
important, why are people able to build big, complex Python
programs (with much shorter time and effort than the strong static
counterparts) without the disaster that I was so sure would ensue?
Anyway, this is probably getting a little off topic for a Cocoa
group, but I think Objective-C does allow both styles.
Ian_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden