views:

480

answers:

6

I had a brainbench exam recently, got high mark, but there were a couple of questions which were hard for me. Maybe it's because english is not my native language... One of the questions is:

Which one of the following describes type-safety?

  1. A programming construct used to ensure the security of reference and value types in the CLR
  2. The protection from memory leakage as a result of disallowing unmanaged access
  3. The CLR-specific feature providing assurances that types may not access memory outside their own AppDomain
  4. A mechanism created to protect assemblies and their types by the use of strong-named keys
  5. The concept dealing with assurances that allocated objects are always accessed in compatible ways

I think it's 1 or 5, but they sound weird to me anyway :(

What do you think?

+5  A: 

Actually I think it's Choice 5 because type safety has nothing to do with Security.

oykuo
You two should fight it out :)
Alan
+1 I think your right
Dead account
I think I agree, but again, poorly worded. I'm not sure it's possible in the English language to come up with a more oblique way of describing type safety than "allocated objects are always accessed in compatible ways".
Joel Mueller
+1  A: 

Choice 5 The concept dealing with assurances that allocated objects are always accessed in compatible ways

Type-safety deals with ensuring that when you create a Foo, you can't treat it as a Bar. If you don't know what type it is (or aren't guaranteed), the code you write simply might not work as expected.

Dave Bauman
A: 

Type-safe languages will make sure (at compile-time) that you don't call incompatible methods on a type, e.g. length() on an int type. Non-type-safe languages will figure it out at runtime. So, choice 5.

Andrew Coleson
This isn't really correct. Type safety has nothing to do with whether typing is static or dynamic. For example C is a statically-typed language that allows and often requires type-unsafe constructs (casts), and Smalltalk is a dynamically-typed type-safe language.
Tyler McHenry
A: 

It is option #5. Type safety is an assurance, not a concrete thing. It is possible for .NET code to not be type safe...say in the case that an assembly uses unsafe code to perform unmanaged calls (PInvoke). During JIT, a process is performed that verifies the types being jitted are, indeed, type safe. I am not aware of any particulars about this process, but if a jitted type passes, then it is considerd verifiably type safe.

jrista
+1  A: 

Type Safety is the feature of a language designed to make good on [Robin Milner][1]'s famous slogan about ML programming: well-typed programs cannot go wrong.

The slogan needs some unpacking before it can be properly understood, but it basically means that programs cannot fail because of a runtime type error, i.e. when the parameters applied to constructor or a function have values of incompatible type.

Consider a language that allows integers, integer functions as first class values, function abstraction and partial function application, and which defines the usual integer arithmetic operators as binary functions. The property of type safety is what the compiler enforces to ensure that both of the arguments to the addition operator are expressions that reduce to integers and not to functions. If a program is well-typed, then the compiler can emit an executable object for it. Otherwise, it flags the programming error and aborts.

james woodyatt
I'd choose option five if I had to take that test.
james woodyatt
A: 

As other have said, choice 5...

In general - for .NET, check out the Common Type System (CTS) which enables cross-language stuff and type safety.

Check out: http://en.wikipedia.org/wiki/Type_safety ...

Gabriel