Could you be a bit less lazy and post the relevant text next time,
rather than forcing people go to download a useless text just to discuss
things with you?
Type safety is the property that no primitive operation is
ever applied to values of the wrong type.
By primitive operation we mean not only addition and so forth, but
also procedure application. In short, a safe language honors the
abstraction boundaries it erects. Since abstractions are crucial for
designing and maintaining large systems, safety is a key software
engineering attribute in a language. (Even most C++ libraries are
safe, but the problem is you have to be sure no legacy C library isn't
performing unsafe operations, too.) Using this concept, we can
construct the following table:
statically checked | not statically checked
type safe | ML, Java | Scheme
type unsafe | C, C++ | assembly
The important thing to remember is, due to the Halting Problem, some
checks simply can never be performed statically; something must always
be deferred to execution time. The trade-off in type design is to
minimize the time and space consumed by these objects during execution
(and, for that matter, how many guarantees a type system can tractably
give a user)—in particular, in shuffling where the set of checked
operations lies between static and dynamic checking.
Basically, the author of the text in question is full of shit by placing
Java in the "statically checked type safe" column. A primitive operation
*can* be applied to values of the wrong type because all objects in Java
derive from java.lang.Object. All one needs to do is cast improperly.
It's *harder*, mind you, to break the type protections in Java, but it's
still not enough to call type safe. I refer you to
<http://www.c2.com/cgi/wiki?JavaArraysBreakTypeSafety>\.
A Java array containing a reference type can be cast to an array of
the supertype. This breaks type safety, and therefore array accesses
have to be type checked at runtime.
For example this code is valid at compile time and fails at run time.
String strings = new String[1];
Object objects = strings;
objects[0] = new Integer(1); // RUN-TIME FAILURE
The author of the text you chose that supports your position also
suggests that "strong typing" is a meaningless phrase, which merely
indicates his own bias. Also on c2, which I consider a bit more rigorous
and authoritative than a random programming language text, see
<http://www.c2.com/cgi/wiki?StaticTypeSafety>\. There's discussion on
there about whether Java is type-safe or not, but someone has also taken
my position:
A "type-safe" language that includes a cast operator is not type-safe.
Ada doesn't have a cast operator. Indeed, creating a subrange type of
Integer (e.g., WholeNumbers = Integer(0..INFINITY)) makes a type that
cannot be cast to Integer at all and is not compatible with Integer on
any level; conversion is possible, but not casting. On the same page:
The point is that because type systems are always "optional", the
alleged benefits of systems based upon them are largely illusory. It's
been my experience that the loudest advocates of strong type systems
have been the youngest developers on the team with the least long-term
support and development experience (based on the number of
applications dealt with, not length of time coding). I therefore
associate (perhaps unfairly) stridency in this regard with youthful
exuberance. -- TomStambaugh.
[...]
I realize, on rereading this, that I strongly endorse the underlying
discipline that results from working in a strongly typed environment.
I think that my view is that it is the *disciplined thought* that is
necessary, not the type system. Thus, I find that the Java and C++
type systems get in the way of the underlying rigor I bring to the
problem space, where as Lisp and Smalltalk environments let me express
that rigor in metastructure. I almost never write totally unstructured
random code. To the contrary, I generally want my code to reflect more
(or at least different) structure from that enforced by a
C++/Java-style static type system. -- TomStambaugh
The discussion is definitely up in the air as to whether Java is really
"type safe" or not. I tend to agree with the position on cast operations
-- which are different than *conversion* operations.
-austin
···
On 9/22/05, Isaac Gouy <igouy@yahoo.com> wrote:
Austin Ziegler wrote:
On 9/22/05, Isaac Gouy <igouy@yahoo.com> wrote:
Humbly suggest that C is not the poster child for static type
checking 
iirc C is not even considered to be type safe.
Humbly suggest that the same applies to Java (java.lang.Object,
anyone?), C++, and even C#. The only type safe statically checked
language that I've used is Ada.
C is statically checked and weakly typed. Ara's point remains the
same -- the compiler doesn't complain about these very *obvious*
programming errors.
I'm not interested in quarreling about the meaning of phrases, so I
use textbook definitions - for "type safety" and "strong typing" see
p271 "Programming Languages: Application and Interpretation"
Programming Languages: Application and Interpretation by Shriram Krishnamurthi
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
