An interesting (or not) thing about C#'s var

[Richard Deeming]

Mycroft Holmes wrote:

var seem way too close to the VB6 variant type

A common misconception. var doesn't mean that your variable is untyped, or typed as object. It just means that the compiler decides what type the variable should be based on the value assigned to it when it is declared.

var s = "Hello"; // Compiles to exactly the same IL as "string s = ..."
s = 42; // Compiler error - cannot assign an Int32 to a String

Totally unlike the Variant type, where the variable could contain anything, and all calls were late-bound:

Dim s As Variant
s = "Hello" ' Oh, it's a string...
s = 42 ' Now it's a Long - that's fine...
Set s = New ADODB.Connection ' An object? No problem...

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Richard Deeming]

John Simmons / outlaw programmer wrote:

Why bother even defining types at all?

Because var doesn't mean "untyped". It means, "the type of this variable is obvious to the compiler, so I don't need to bother writing it".

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Lost User]

N_tro_P wrote:

Are you seriously having issues over a hyphen

No. Just the difference with compile-time :)

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

[Lost User]

John Simmons / outlaw programmer wrote:

If it's so goddamn wonderful, why require its use at all?

It's not required. The post was showing a nice benefit. If you don't like benefits... Well, that's your problem I guess.

John Simmons / outlaw programmer wrote:

Why bother even defining types at all?

Why bother using high level languages? Why not just code in 1s and 0s? Yeah, silly question in response to a silly question. The fact is strong types are needed, but in my experience quite rarely. Weak types allow for improved architectural principles like development views and extensibility. The argument often made is the is errors that occur, but it is in fact a red herring in that the systems testability (another architectural principle) is lacking. That's not to say it has to be, but due to budget or lack of developer concern for tests or some other poorly justified reason it has been omitted from the system. The logic then becomes circular. We don't like it cause we found an error one time when someone used it. The truth is the error existed not because of var, and the nay sayers will usually acknowledge this. Where the gap is then, is on how it would have been caught or observed otherwise. Which goes back to testing. The testing should have been in place regardless, because it actually catches errors. Saying we use strong types because it catches errors is not observing the real issue. For one, strong types won't catch all of the errors. For two, proper testing would catch the same errors even if weak typed. Therefore, it is a red herring.

Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.

[Lost User]

Your example would not have a "compile-time" error. It would result in a "run-time" error if it was a bad cast.

Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.

[Lost User]

Eddy Vluggen wrote:

No. Just the difference with compile-time :)

Your example would not result in a "compile-time" error but in fact a "run-time" error. Proof:

public interface IThingy
{

}

public class Parent : IThingy
{

}

public class Child : Parent
{

}

public class Monkey
{

}

public class User
{
    public void Test()
    {
        var monkey = new Monkey();
        var child = (IThingy)monkey;

    }
}

This code compiles and will result in a bad casting exception. You are likely confusing concrete object casting which will result in a "compile-time" error (e.g. if monkey were cast to "Child"), but that was NOT the example you provided. You in fact specifically called out the usage of interfaces, which will result in a "run-time" error. " :) "

Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.

[Mladen Jankovic]

Type inference[^]

GeoGame for Windows Phone | The Lounge Explained In 5 Minutes

[Jeremy Falcon]

Trust me, I've already learned that N_tro_P simply does nothing but call everyone stupid and argues. You can't win with someone on a podium thinking he's better than everyone. For what it's worth, I'm very pro var and I still agree with your points. I'll still use var personally, but I still agree with your points. So rest assured, there are pro var people out there that do listen. :-D

Jeremy Falcon

[Jeremy Falcon]

Bingo!

Jeremy Falcon

[Jeremy Falcon]

Don't confuse var with dynamic.

Jeremy Falcon

[Sander Rossel]

Ahhh... The sound of reason, I've missed it in these parts :D I'm not pro-var and not anti-var, not sure how var I'll go :D

Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.

Simplicity is prerequisite for reliability. — Edsger W. Dijkstra

Regards, Sander