Coffeehouse Thread

43 posts

any plans to make C# more dynamic in future?

Back to Forum: Coffeehouse
  • User profile image
    Human​Compiler

    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.

  • User profile image
    Ion Todirel

    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 = ...

  • User profile image
    littleguru

    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...

  • User profile image
    littleguru

    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! Tongue Out 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.

  • User profile image
    Andrew Davey

    .NET already allows methods to be created and invoked at runtime. Take a look inside System.Reflection.Emit. Classes like DynamicMethod let you inject code on the fly into the AppDomain. In C# this involves knowing MSIL - not exactly great fun Wink However if you are using a .NET language with syntactic macro features then you can hide away all the IL.

    Generating functions at runtime can be amazingly powerful and make some impressive performance gains. However they are hard to debug. It would great to see a future version of Visual Studio with better abilities to debug dynamically generated code.

    However, I must say that I'm all for strong-typing. I think the functional programmers have the right idea. Once you get a functional program past the type checker the chance of runtime errors is much less than that of imperative code IMO. By not having mutable data structures your program is much safer. Yes it can be harder to get your head around the code at first, but the longer term benefits are worth it. For example, functional programs are trivially parallelised. I think we will see more functional style constructs coming to C# (such as lambda expressions). This can only be a good thing. Smiley

  • User profile image
    Jeff Spicolli

    littleguru wrote:
    
    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 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";



    VB 6 is long over!


    Thank God!

    Variants were a terrible idea.

    Try storing them in the COM+ SPM, loads of inconsistant fun!

    littleguru wrote:
    

    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.


    That is an understatement.

    If this guy wants a dynamic language so bad, and can't accomplish his task with what is available in the language now, then I would argue his design is flawed.

  • User profile image
    Human​Compiler

    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.

  • User profile image
    Jeff Spicolli

    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.


    Don't hassle it, I gotcha bud.

    That said VB 5/6 variants still suck(ed) and were a terrible idea, the product of which was many unhappy hours spent tracking down a bug whose type had unexpectedly shifted.

    /All I need is a cool buzz and some tasty waves (and no variant types!)

  • User profile image
    Jeff Spicolli

    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).


    Thanks, that is an interesting article, and an interesting concept, but not sure if I will ever use it.

    One of the key points of Agile Programming is Clarity / Readability.

    And that structure isn't either of those from what I have seen so far.

    That doesn't mean it's right or wrong, it just means that from how I am understanding it today, I will never use it, ever.

  • User profile image
    Ion Todirel

    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

  • User profile image
    littleguru

    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?

  • User profile image
    Andrew Davey

    "var" is simply a shorthand notation. It tells the compiler to infer the type of the expression on the right-hand side. This is done at compile time obviously. Therefore the IL generated is exactly the same as what would be there if you had entered the type of the variable by hand.

    e.g.
    int GetValue() { return 42; }
    ...
    var foo = GetValue();

    is exactly the same as
    int GetValue() { return 42; }
    ...
    int foo = GetValue();

    foo is an int, plain and simple. In fact I bet intellisense will tell you so if you hover over the variable!

    So when you call some function in C# 2.0 you look at the return type yourself and declare a variable to match it. In C#3.0 the compiler is able to declare the correct type on your behalf - basically cutting down on a loads of key presses Smiley

    "var" becomes very useful when you get into using anonymous types. But that's a whole other story... Wink

  • User profile image
    littleguru

    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. Smiley

    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.

  • User profile image
    Ion Todirel

    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.

  • User profile image
    littleguru

    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);

  • User profile image
    Ion Todirel

    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! 

  • User profile image
    littleguru

    Fine Smiley I'll read it Smiley 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!!

  • User profile image
    littleguru

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

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.