To BCL or Not to BCL

Debate rages on:

• 
  
  Use the BCL type names
  
  
• 
  
  Don't redefine your type's names to match your old habits ;-)

[Ingo Rammer's DotNetCentric]

Sorry.... string, int, char and long are part of the language. Int32 is just some detail of the underlying platform. The fact that C# and VB.NET very convienently map onto the CLR type system doesn't mean that all languages do. Using BCL types also takes away the flexibility only a high level language and its abstraction over the platform can provide. Mind WPARAM and LPARAM in Win16 (16bits,32bits) vs. Win32 (32bits) vs. Win64 (64bits). (For the younger amongst us, the "W" in WPARAM used to mean "WORD" as in "16bit processor word" and "L" used to mean "LONG" as in, ahem, "long" or "double word"). Been there, hated that. If a language can fix those problems for me by providing a layer of abstraction ... thank you, will buy. [Clemens Vasters' Enterprise Development & Alien Abductions]

Sorry again...I don't think I quite agree. Reading the C# specification, int is defined as a 32 bit integer, period. In fact, the specification even says:

Each of the predefined types is shorthand for a system-provided type. For example, the keyword int refers to the struct System.Int32.

So I don't think I understand the comment about this in any way taking away flexibility. The platform abstraction is provided by the CLR, not the language. Given that the biggest problem with WPARAM and LPARAM (and int) was the fact that they changed size, I would think tying the language keyword to a particular type is a good thing. If you really need a type that means "the sort of natural size of the underlying platform" that's what System.IntPtr is for.

Also, we can certainly use the type names (as opposed to the keywords) in C# and VB.NET only. If there are other languages that provide a "layer of abstraction," then great. In the meantime, given how many times I've had to explain to people that int and System.Int32 are the same thing, that a long is actually always 64 bits, and that Integer in VB.NET is 32 bits not 16, I think using the CLR type names is a great idea, particularly in sample code.

Of course, the spec also says:

As a matter of style, use of the keyword is favored over use of the complete system type name.

and as with any question of style there is no "right" answer. :)