Path: utzoo!news-server.csri.toronto.edu!rutgers!mcnc!gatech!udel!cis.udel.edu
From: carroll@cis.udel.edu (Mark Carroll)
Newsgroups: comp.lang.c++
Subject: Re: Static typing, OOP efficiency, and programmer error
Message-ID: <47199@nigel.ee.udel.edu>
Date: 11 Mar 91 16:07:52 GMT
References: <PCG.91Feb27190941@odin.cs.aber.ac.uk> <27CE9C05.4F64@tct.uucp> <1860@news.tcs.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 75
Nntp-Posting-Host: sol.cis.udel.edu

In article <1860@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes:
]In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:
]|> According to pcg@cs.aber.ac.uk (Piercarlo Grandi):
]|> chip> Besides, as far as I know, there is no guarantee that the message
]|> chip> set supported by a given class will not expand after the users of
]|> chip> that class have already been compiled.
]|> 
]|> pcg> The idea in Objective C is that you resolve statically what you
]can, and
]|> pcg> turn to dynamic overloading for what you cannot.
]|> 
]|> But the Objective C compiler never knows when you have made an error
]|> by sending a message that the recipient cannot understand.  That error
]|> is impossible in a C++ program.
]|> 
]|> pcg> ... [in Objective C, a message] just gets resolved dynamically
]instead of
]|> pcg> statically. In C++ you simply don't have this option in the
]general case.
]|> 
]|> True.  I consider this omission a feature, personally; it keeps me
]|> from discovering at run-time that I have requested an impossible
]|> operation -- an error the compiler could have detected.
]
]     I would consider this sort of run-time error checking inadvisable for
]commercial products, to say nothing of mission critical applications,
]although I'm sure there are people out there using Objective C and Smalltalk
]for commercial systems.  It simply isn't a good idea for a sold product in
]customer hands to crash with an error.  (Yeah, I've seen commercial systems
]core dump, too.  :-)  It's just easier to have high confidence in software
]which does as much error checking as possible at compile time.  Of course,
]if one just performed exhaustive testing before releasing a product . . . .
]

I think that you're missing something fairly important here.

The fact that Objective-C is primarily dynamically bound does not mean
that it is any less safe than a fully statically bound language in the
general case.

Most of the time, Objective-C is used in a way which could be trivially
translated into a fully static language like C++. In those cases, Objective-C
COULD catch any of the errors which C++ could catch. (I don't know if the
Stepstone compiler actually does, but by using dataflow analysis to bind
statically whenever possible, any of the errors that could be caught statically
in C++ could be caught statically in Objective-C. Objective-C just transfers
the burden to the compiler, rather than the programmer.) 

In other cases, when you are expressing something as a message pass that
could not be expressed as a member function call in C++ (i.e., using the
perform: method), you are doing something "less safe" than you would in 
C++. But those cases are easy to identify in the code, and by scaffolding 
them inside of a safety test (low budget assertion testing...), you can 
insure that they will indeed execute safely.

Basically, I think this whole mess comes down to this:
	Static versus dynamic binding is a matter of personal taste.

I personally very much prefer to work with a more dynamic language. I think
that my programs are much more elegant written in a dynamic style, and I 
think that my code written in a dynamic language is much better than my 
code written in a static language. So, when I need to use a C-family language,
I'll stick with Objective-C. If you like static programming, you'll think
that I'm out of my gourd, that I'm a fool, or whatever, and you'll stick
with your static language.

]							George

	<MC>

-- 
---------------------- Mark Craig Carroll:  <MC> ------------------------
------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------
-- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu --
---------------------- Shalom Achshav - Peace NOW! ----------------------