Coffeehouse Thread

52 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

C# to VBish in .NET 3.0?

Back to Forum: Coffeehouse
  • User profile image
    stun

    I just want to confirm whether this is true or not.
    I just found this article that someone posted about a new language feature in C# 3.0 .NET.

    See URL = http://www.codepost.org/view/126


    If this is true, WHY WHY WHY ???
    GOD NO !!!! Please don't make C# go the VB way.


    // C# 2.0 behavior
    int i = 10;
    string s = "Hello codepost visitors!";

    // New C# 3.0 var type Perplexed
    var i = 5;
    var s = "Hello again!";



    Can anyone confirm please?

    Thanks

  • User profile image
    jmbledsoe

    This isn't the VB way at all, thank God.  VB (by default, and as far as I know) doesn't do any type checking at compile time.  You can just call methods on objects and everything will compile just fine.  You'll blow up at runtime if you did it wrong, though.  Perplexed

    The var keyword just tells the compiler to infer the strong type of the variable from its initial value.  From the rest of the article:

    The var keyword is NOT a completely new type, instead the compiler just takes a look at the right-hand side of the expression. If the right-hand side is an int, for example, the compiler will "replace" the var keyword with int. This means that the following contruction will NOT work:

    CODE: CSHARP
    // Will not work, 'cause the right-hand side of the var is unknown
    var b;
    b = 1337;


  • User profile image
    JohnAskew

    jmbledsoe wrote:
    This isn't the VB way at all, thank God.  VB (by default, and as far as I know) doesn't do any type checking at compile time.  You can just call methods on objects and everything will compile just fine.  You'll blow up at runtime if you did it wrong, though. 

    The var keyword just tells the compiler to infer the strong type of the variable from its initial value.  From the rest of the article:

    The var keyword is NOT a completely new type, instead the compiler just takes a look at the right-hand side of the expression. If the right-hand side is an int, for example, the compiler will "replace" the var keyword with int. This means that the following contruction will NOT work:

    CODE: CSHARP
    // Will not work, 'cause the right-hand side of the var is unknown
    var b;
    b = 1337;





    So this is not the ugly old Variant we all love to hate from VB. Good.

    Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?


    * the more I look at this, the less I understand...

  • User profile image
    TommyCarlier

    It's a compiler trick: the compiler just translates var x = 1337; to int x = 1337;
    This is very nice in situations like this:
    Dictionary<int, string> d = new Dictionary<int, string>();
    => var d = new Dictionary<int, string>();

  • User profile image
    Rotem Kirshenbaum

    The same way he knows how to handle this:

    object o = 56;

    Rotem

  • User profile image
    Antitorgo

    JohnAskew wrote:
    So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.

  • User profile image
    Sampy

    jmbledsoe wrote:
    VB (by default, and as far as I know) doesn't do any type checking at compile time.  You can just call methods on objects and everything will compile just fine.  You'll blow up at runtime if you did it wrong, though. 


    This is very, very wrong. VB will do compile-time checking just like C#.

    There are ways to do late binding but only on things of type Object.

  • User profile image
    phreaks

    Antitorgo wrote:
    
    JohnAskew wrote: So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.


    Right, God forbid you have to actually use interfaces or inheritance.
    Hey let's make it *easier*.

    pfft,  it's junk that will make your code smell bad.

    /EDIT:

    Really makes me wonder what is going on over there at MS, for the last 4 years, they have had their evangelists espousing the clarity and purity of Agile Goodness, then they introduce this idea, which completely contradicts those philosophies.

  • User profile image
    JohnAskew

    Antitorgo wrote:
    
    JohnAskew wrote: So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.


    Excellent.

    I have to research LINQ. 

    'var' is a type-safe anonymous type. 

    Not an "any-type" variable / container.

    The compiler will type 'var' in cement, no chance to reuse it for another type at run-time. Sweet.

    It seems the use of those three letters in succession 'v-a-r' will cause plenty of angst in the community.


  • User profile image
    Sven Groot

    thumbtacks wrote:
    var x = 56;

    How is the compiler going to know if you meant an integer or a real number?

    To the compiler, it doesn't matter what you meant. Smiley

    A numerical constant that is a whole number is always an integer in C# (C/C++ too). If you want it to be a real number, you have to write 56.0, which makes it a double. If you want it to be a float, you have to write 56.0f. For an decimal, write 56.0d.

    This usually doesn't matter because most numerical types will silently convert to one another. A typical case where it does matter is divison: x / 56 will yield and integer result, x / 56.0 will yield a real result, which can make a big difference.

  • User profile image
    Antitorgo

    phreaks wrote:
    

    Right, God forbid you have to actually use interfaces or inheritance.
    Hey let's make it *easier*.



    Who said interfaces or inheritance are going away? It is just syntactic sugar.

    var x = new System.Data.DataSet();
    if (x is IListSource)
       Console.WriteLine("Is an IListSource");

    is the same as:

    System.Data.DataSet x = new System.Data.DataSet();
    if (x is IListSource)
       Console.WriteLine("Is an IListSource");

    Both will compile and return the same thing...

  • User profile image
    JohnAskew

    phreaks wrote:
    
    Antitorgo wrote: 
    JohnAskew wrote: So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.


    Right, God forbid you have to actually use interfaces or inheritance.
    Hey let's make it *easier*.

    pfft,  it's junk that will make your code smell bad.

    /EDIT:

    Really makes me wonder what is going on over there at MS, for the last 4 years, they have had their evangelists espousing the clarity and purity of Agile Goodness, then they introduce this idea, which completely contradicts those philosophies.




    I'm going to have to disagree with you.

    One of us hasn't done enough research.

  • User profile image
    jmbledsoe

    Sampy wrote:
    
    jmbledsoe wrote:VB (by default, and as far as I know) doesn't do any type checking at compile time.  You can just call methods on objects and everything will compile just fine.  You'll blow up at runtime if you did it wrong, though. 


    This is very, very wrong. VB will do compile-time checking just like C#.

    There are ways to do late binding but only on things of type Object.

    Embarassed You're correct of couse.  I'm thinking more about VBScript it seems.

    Still, without having /optionstrict set, VB will let you compile something like this:

    Dim x As Object = New ArrayList
    Dim y As Boolean = x

    Yucky  Expressionless

  • User profile image
    Antitorgo

    JohnAskew wrote:
    Excellent.

    I have to research LINQ. 

    'var' is a type-safe anonymous type. 

    Not an "any-type" variable / container.

    The compiler will type 'var' in cement, no chance to reuse it for another type at run-time. Sweet.

    It seems the use of those three letters in succession 'v-a-r' will cause plenty of angst in the community.



    Well, 'var' isn't a type-safe anonymous type, it is just there to facilitate them.

    var s = "My String";

    is a perfectly valid point of non-anonymous class usage of 'var'.

    As far as the 'v-a-r' causing angst, it already has and some people were saying they'd rather see it called 'inferred' or something like that... Personally I'd rather keep it something short, so 'var' is fine with me.

    Here's a good C9 vid of Anders talking about LINQ and the whole C9 thread is fairly interesting reading: LINQ

  • User profile image
    phreaks

    JohnAskew wrote:
    
    phreaks wrote: 
    Antitorgo wrote: 
    JohnAskew wrote: So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.


    Right, God forbid you have to actually use interfaces or inheritance.
    Hey let's make it *easier*.

    pfft,  it's junk that will make your code smell bad.

    /EDIT:

    Really makes me wonder what is going on over there at MS, for the last 4 years, they have had their evangelists espousing the clarity and purity of Agile Goodness, then they introduce this idea, which completely contradicts those philosophies.



    I'm going to have to disagree with you.

    One of us hasn't done enough research.


    Do you know Code Smells? It has nothing to do with research.  I am not a simpleton (arguably), I understand the premise, it removes the notion of static typing from C#. (OK, well not exactly, but gives it an air or feel of dynamic typing)

    Wait until you inherit some project from someone and it is littered with 

    private MyClass myClass;
    var y;

    void init() {
     y = new MyClass(somevalue);
     myClass = y;
    }

    //hundreds of lines of code

    void my ObscureMethod() {
    var x = y;
    }

    Because the entire notion smells alot like Speculative Generality to me.

    If you think it won't happen, think again!

    http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLJ,GGLJ:2006-33,GGLJ:en&q=%22code+smells%22+Speculative+generality


    /edit:
    if you guys like it, more power to you, I think it's a horrible idea. I can't think of a single task that I will be able to do using "var"; that I can not accomplish now.

    So what is the point?

  • User profile image
    ktr

    phreaks wrote:
    
    JohnAskew wrote:
    phreaks wrote: 
    Antitorgo wrote: 
    JohnAskew wrote: So this is not the ugly old Variant we all love to hate from VB. Good.Is this a "stub" for Reflection to use to supply the correct type at runtime or is this done at only compile time (if so what's the point)?* the more I look at this, the less I understand...

    No, it isn't the ugly old Variant.
    From my understanding, it really is put in place to handle anonymous types which are one of the key features for LINQ.

    Maybe this link will help explain it better.

    The key being that with LINQ it is creating an anonymous class for you based on the criteria specified. Without VAR it would be a pain in the (I need to watch my language) to have to write non-anonymous classes to hold the data coming back from the LINQ query.


    Right, God forbid you have to actually use interfaces or inheritance.
    Hey let's make it *easier*.

    pfft,  it's junk that will make your code smell bad.

    /EDIT:

    Really makes me wonder what is going on over there at MS, for the last 4 years, they have had their evangelists espousing the clarity and purity of Agile Goodness, then they introduce this idea, which completely contradicts those philosophies.



    I'm going to have to disagree with you.

    One of us hasn't done enough research.


    Do you know Code Smells? It has nothing to do with research.  I am not a simpleton (arguably), I understand the premise, it removes the notion of static typing from C#. (OK, well not exactly, but gives it an air or feel of dynamic typing)

    Wait until you inherit some project from someone and it is littered with 

    private MyClass myClass;

    void init() {
     var y = new MyClass(somevalue);
     myClass = y;
    }

    //hundreds of lines of code

    void my ObscureMethod() {
    var x = y;
    }

    Because the entire notion smells alot like Speculative Generality to me.

    If you think it won't happen, think again!

    http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLJ,GGLJ:2006-33,GGLJ:en&q=%22code+smells%22+Speculative+generality


    /edit:
    if you guys like it, more power to you, I think it's a horrible idea. I can't think of a single task that I will be able to do using "var"; that I can not accomplish now.

    So what is the point?



    Believe it or not, there is a point. The big new thing for C# 3.0 is not “var” ... it’s anonymous types (mainly to support LINQ). Meaning you can have a type which is not defined in a class. Without the var keyword, it would be impossible to create these types. Think about it. An anonymous type has no name. It is inferred. That’s the whole purpose of var.

  • User profile image
    kettch

    phreaks wrote:
    
    Wait until you inherit some project from someone and it is littered with 

    private MyClass myClass;

    void init() {
     var y = new MyClass(somevalue);
     myClass = y;
    }

    //hundreds of lines of code

    void my ObscureMethod() {
    var x = y;
    }


    /edit:
    if you guys like it, more power to you, I think it's a horrible idea. I can't think of a single task that I will be able to do using "var"; that I can not accomplish now.

    So what is the point?


    First of all, that code won't compile. I'm pretty sure Var is used for local variables only. Heck, that code won't compile with an int or a string either.

    Even if a var were declared at the top of a method and sprinkled around elsewhere, all you would have to do is mouseover it. The compiler tags all references to that particular var with it's inferred type. Whenever you come across a variable that you have forgotten the type of, you either mouseover it, or perhaps rely on your code standards to infer the type from the name.

    Second, I think that var is necessary if you ever expect to use any of the features of LINQ. It might not be required (i'd have to check on that) but it will be mighty inconvenient. Perhaps you should go read the specifications. Var is far more structured and restricted than you understand it to be.

  • User profile image
    Antitorgo

    kettch wrote:
    
    phreaks wrote: 
    Wait until you inherit some project from someone and it is littered with 

    private MyClass myClass;

    void init() {
     var y = new MyClass(somevalue);
     myClass = y;
    }

    //hundreds of lines of code

    void my ObscureMethod() {
    var x = y;
    }


    /edit:
    if you guys like it, more power to you, I think it's a horrible idea. I can't think of a single task that I will be able to do using "var"; that I can not accomplish now.

    So what is the point?


    First of all, that code won't compile. I'm pretty sure Var is used for local variables only. Heck, that code won't compile with an int or a string either.

    Even if a var were declared at the top of a method and sprinkled around elsewhere, all you would have to do is mouseover it. The compiler tags all references to that particular var with it's inferred type. Whenever you come across a variable that you have forgotten the type of, you either mouseover it, or perhaps rely on your code standards to infer the type from the name.

    Second, I think that var is necessary if you ever expect to use any of the features of LINQ. It might not be required (i'd have to check on that) but it will be mighty inconvenient. Perhaps you should go read the specifications. Var is far more structured and restricted than you understand it to be.


    Correct, 'var' is local only, so the above code wouldn't even come close to compiling.

    As far as LINQ working w/o anonymous types -- yes, it does work. I'd much rather just use the anonymous types though. Creating a class heirarchy 'by-hand' for LINQ could quickly become a pain. Especially when the schema changes.

    What strikes me as odd as why would anyone complain about an easier way to strongly type db queries? I mean, how much better can it get when you can catch db type mismatches at compile time?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.