any plans to make C# more dynamic in future?

littleguru wrote:

I had to maintain code in old VB 4,5,6... It's a pain.

variant b = 1
b = "123"
b = 1.2

That's not how var in C# 3.0 works.  I forget the word for it, so i'll make one up and hope that's what it is, but I'd call it implicit typing instead of explicit typing.  (someone correct me on what the real verbage is if you know).

If you said this...

var b = 1;
b = "123";

...you'd get an exception.  When the variable was declared, it's type was set.  It's dynamic because when you do things like database queries or whatever in LINQ the type isn't really set until it's called.

I've been out of this stuff for a while so if there are any details I botched up, let me know, but I believe the general idea is correct.

HumanCompiler wrote:

That's not how var in C# 3.0 works.  I forget the word for it, so i'll make one up and hope that's what it is, but I'd call it implicit typing...

That's right, implicitly typed local variable. var stands for... variable.

Imagine this:

Dim somethingStrange As new ...

and this (not funny)

Dictionary<string, Dictionary<int, NameValueCollection>> somethingStrange = new ...

and this (now i'm happy, looks like VB style)

var somethingStrange = ...

It's getting harder to understand what the code does, if the type is set at run time. I like it when the compiler already complains about problems during compile time. I don't like the runtime complaining about something. That's way to late. At least in my eyes. That's also why I don't like the way how ADO.NET is currently implemented (besides type safe data sets). It's all so dynamic and full of strange errors that happen just once each week or each day and nobody can reproduce them.

My problem with too dynamic languages are those hidden errors and traps. I don't like errors that are hard to reproduce! If the final user gets them each week, she/he starts to think that the program isn't done well...

HumanCompiler wrote:



littleguru wrote: I had to maintain code in old VB 4,5,6... It's a pain. variant b = 1 b = "123" b = 1.2

That's not how var in C# 3.0 works.  I forget the word for it, so i'll make one up and hope that's what it is, but I'd call it implicit typing instead of explicit typing.  (someone correct me on what the real verbage is if you know).

If you said this...

var b = 1;
b = "123";

...you'd get an exception.  When the variable was declared, it's type was set.  It's dynamic because when you do things like database queries or whatever in LINQ the type isn't really set until it's called.

I've been out of this stuff for a while so if there are any details I botched up, let me know, but I believe the general idea is correct.

VB 6 is long over! My point was that you can't get it from looking at the variable definition. You need to run the code and have a look at all places where the variable could get initialized to understand which type it actually is... You don't have one single type you have a set of types.

Hard time to debug.

I don't think you guys really get what var does.  var != Variant (VB6).  Variant in VB6 was sort of like what Object is in .NET.  var is completely different (and no it doesn't work like var in Javascript does either).

As I said before, when you declare a variable using var, it implicitly infers it's type and is that type from then on and can not be changed otherwise.  It's still strongly typed.  It's just that the type is inferred by what's on the right side of the evaluation.

jaylittle wrote:

It's not just about data types and strongly typing things guys, try this article from Joel on the subject (which has been posted here before).

here

HumanCompiler wrote:

I don't think you guys really get what var does.  var != Variant (VB6).  Variant in VB6 was sort of like what Object is in .NET.  var is completely different (and no it doesn't work like var in Javascript does either).

As I said before, when you declare a variable using var, it implicitly infers it's type and is that type from then on and can not be changed otherwise.  It's still strongly typed.  It's just that the type is inferred by what's on the right side of the evaluation.

We got you... So something like this is not possible:

var foo = null;
if (bar)
  foo = "value value value";
else
  foo = 123;

If that is possible it is also a point of problems... At least in my eyes. Anyway. I hope that "var" is not going to spead to much...

Is overloading of methods handled properly by var?

Foo(int i);
Foo(string s);

var v = "string";
Foo(v);

Does that work? Is there any good documentation about "var" available?

Hmmm... I still don't see why it has been introduced. I mean you can do the exact same without it and it does not bring much advantages. I wonder what the reason was... I mean the real reason to create the thing.

I mean if the type is already checked at compile time it is OK. I hope they are not pushing to much stuff into runtime.

I know that .NET is never going to have weak type checking. It is one of the biggest pros of .NET to have strong type checking algorithms. They avoid a lot of the old problems. I think that .NET is going into the right direction and there are a lot smart minds behind the creation of the runtime and languages. Keep it rocking guys.

littleguru wrote:

Hmmm... I still don't see why it has been introduced. I mean you can do the exact same without it and it does not bring much advantages.

OK, here:

List<Dictionary<Dictionary<int, List<Dictionary<string, NameValueCollection>>>, Hashtable>> foo = new List<Dictionary<Dictionary<int, List<Dictionary<string, NameValueCollection>>>, Hashtable>>();

with C#3.0 you just do it like this:

var foo = new List<Dictionary<Dictionary<int, List<Dictionary<string, NameValueCollection>>>, Hashtable>>();

you don't have to declare type (that ugly type) two times, is like in VB with Dim.

Another reason for var its for anonymous types:

var foo = new { Name="Unknown", Alias="littleguru" };

It's also easy to write LINQ statements, var helps a lot.

Wow! Once you have such nested generic types, you should switch to a custom class (create an own class). That makes the code also more readable and a lot shorter! Nesting more then one (or two) generic type makes it very hard to maintain the code. First it makes sense, as the method or class, where you use this type is little. But give it time and enjoy maintaining the code after a few years.

"var" is nice for "on the fly creation of types". But I can't see that it gives you intellisense... Or isn't something like that possible with var?

public var Foo(bool b)
{
    if (b)
       return true;
    return Foo1(!b);
}

public var Foo1(bool b)
{
    if (b)
      return Foo2(b);
    return 1.2;
}

public var Foo2(bool b)
{
    if (b)
      return "test";
    return b;
}

var foo = Foo(false);

littleguru wrote:

Or isn't something like that possible with var?

public var Foo(bool b)
{
    if (b)
       return true;
    return Foo1(!b);
}

you can't do that with var, read C#3.0 Specifications, 1. Implicitly typed local variables! 

Fine I'll read it I did not have much time lately ... that's why I'm not completely up to date, but I'll bring me back soon. It's great that the thing is only allowed for local variables. It's OK then!!

Wow! I like C# 3.0 - Nice work so far It's well thought and very VERY nice