Tech Off Thread

28 posts

Forum Read Only

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

Enumerations and Nothing

Back to Forum: Tech Off
  • User profile image
    W3bbo

    'lo

    I noticed something...

    When you set an Enumeration Property to "Nothing" it isn't set to a null value. Instead it gets set to whatever value "Zero" is.

    Consider this:


    Public Enum Foo

    Bar = 0
    Baz = 1
    Blargh = 2

    End Enum

    Public Class Bill

    Private _F As Foo

    Public Property F As Foo
    Get
    Return _F
    End Get
    Set (Value As Foo)
    _F = Value
    End Set
    End Property

    End Class

    Public Sub Main()

    Dim B As New Bill()
    B.F = 1
    Console.WriteLine(B.F) ' Prints "Baz"
    B.F = 0
    Console.WriteLine(B.F) ' Prints "Bar"
    B.F = Nothing
    Console.WriteLine(B.F) ' Prints "Bar" too

    End Sub

    This is kinda disruptive, since I've written about 500 lines that assume that setting an enumeration to Nothing returns a null value, rather than the Zero value.

    Does anyone know a workaround for this

  • User profile image
    jorupp

    Enum extends ValueType, which can't be null.  If you need it to be nullable, you'll need to use Nullable<Foo> in .NET 2.0.  One option I've used in 1.x apps is to add a 'None' member, make it the first value in the enum, and use that instead of null.  It's the same problem you have with other value types (int/char/byte/struct, etc.).

  • User profile image
    TomasDeml

    Null/Nothing == 0 in the World of value types...

  • User profile image
    W3bbo

    jorupp wrote:
    One option I've used in 1.x apps is to add a 'None' member, make it the first value in the enum, and use that instead of null.


    Yep, that's the solution I opted for.

  • User profile image
    mule

    You can set an Enum to Nothing in VB.NET?  Time you switched to C#, then you wouldn't be rewriting all that code. Yuk!

  • User profile image
    W3bbo

    mule wrote:

    You can set an Enum to Nothing in VB.NET?  Time you switched to C#, then you wouldn't be rewriting all that code. Yuk!



    Sorry, but VB's syntax is soooo much more read/writable.

    What would you prefer?


    System.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumeratorSystem.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumerator  Enumerator = new System.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumeratorSystem.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumerator();


    Or this:


    Imports X509 = System.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumeratorSystem.Security.Cryptography.X509Certificates.X509CertificateCollection

    Dim Enumerator As New X509.CertificateEnumerator()


    Hmmm? Wink

  • User profile image
    mule

    I think I prefer:

    using x509Enumerator = System.Security.Cryptography.X509Certificates.X509CertificateCollection.X509CertificateEnumerator;

    x509Enumerator enumerator = new x509Enumerator();

    YMMV!

     

    That's the first time I've heard someone try to claim preferring VB because it is less verbose than C#.  I'm impressed you found an example Smiley

  • User profile image
    wacko

    What’s interesting is the example he did find really is not an example at all, since as you have shown his reasoning for using VB over c# is not true.

    I know of college professors that will now even allow you to take there courses if you have even touched any level VB or a Basic language as they think it teaches bad design and some of the worst looking code ever.

  • User profile image
    W3bbo

    wacko wrote:
    What’s interesting is the example he did find really is not an example at all, since as you have shown his reasoning for using VB over c# is not true.


    Okay, I was exgadderating.

    The Namespace Alias thing applies to both languages, but I just like VB's New operator that doesn't requires the "= <Classname>()" bit at the end (which seems rather pointless).

    Here's a suggestion for C#3:

    Instead of:

    System.Collections.ArrayList AL = new System.Collections.ArrayList();

    How 'bout this:

    new System.Collections.ArrayList AL;

    ?

  • User profile image
    wacko

    I guess you could always shorten it up a little with

    var x = new ArrayList();

    I mean thats a lot cleaner then before and it works in c# 3.0

  • User profile image
    Red5

    wacko wrote:
    I know of college professors that will now even allow you to take there courses if you have even touched any level VB or a Basic language as they think it teaches bad design and some of the worst looking code ever.


    I find this hard to believe.  What type of institution prohibits learning based on previous knowledge of a subject?

  • User profile image
    Deactivated User

    Comment removed at user's request.

  • User profile image
    blowdart

    W3bbo wrote:
    The Namespace Alias thing applies to both languages, but I just like VB's New operator that doesn't requires the "= <Classname>()" bit at the end (which seems rather pointless).

    Here's a suggestion for C#3:

    Instead of:

    System.Collections.ArrayList AL = new System.Collections.ArrayList();

    How 'bout this:

    new System.Collections.ArrayList AL;

    ?


    Because it's nowhere near the same thing. Maybe it's my C and C++ background but there is no way C# should make assumptions about what type of objects are being created based on the type of the object pointing to them. Heck if you couldn't do

    IAnything factory = new Concrete();

    then you can throw a lot of patterns away.

  • User profile image
    Human​Compiler

    blowdart wrote:
    W3bbo wrote: The Namespace Alias thing applies to both languages, but I just like VB's New operator that doesn't requires the "= <Classname>()" bit at the end (which seems rather pointless).

    Here's a suggestion for C#3:

    Instead of:

    System.Collections.ArrayList AL = new System.Collections.ArrayList();

    How 'bout this:

    new System.Collections.ArrayList AL;

    ?


    Because it's nowhere near the same thing. Maybe it's my C and C++ background but there is no way C# should make assumptions about what type of objects are being created based on the type of the object pointing to them. Heck if you couldn't do

    IAnything factory = new Concrete();

    then you can throw a lot of patterns away.


    Sorry you feel that way.  Wink  C# 3.0 (and VB 9.0) will support that.

    Try this...

    C#
    var x = new ArrayList();

    VB
    Dim x = New ArrayList()

    Then roll over the variable down the line in your code.  It will show x as an ArrayList.  The feature is called Infered Types and is key to LINQ.  Not that I'd recommend you go around declaring things without types, but I don't really see what's so bad about it.  We're not talking implicit conversions or anything like variant types.  Smiley

  • User profile image
    wacko

    I am not stating that I personally object to either, I happen to like c# over vb.net but that does not mean that I do not happen to program in vb.net. What I stated is not a lie its is the turth that some people take a distate in VB because of is messyness per say. This does not reflect my personal opinion as I program in both. I mean there are jobs out that people who program in vb.net will not always get picked over those who program in c# if the job requires c#. I mean there is a reality that some just dislike it more then others.

    To mention on what blowdart stated one reason we often times could not see something like new arraylist Al; is because of the very nature of c# and the way it creates its objects over VB. One thing I would like to see come to c# is late binding which you can do but it requires far more work then that of vb.net. I mean

    Var x = 1;

    x = "hello";

    that just doesn't work and to me that seems lacking, it would be nice at runtime If could define what x was but sadly that is not a feature of the c# lang.

  • User profile image
    wacko

    I mentioned this in my above post Smiley

  • User profile image
    blowdart

    HumanCompiler wrote:


    Then roll over the variable down the line in your code.  It will show x as an ArrayList.  The feature is called Infered Types and is key to LINQ.  Not that I'd recommend you go around declaring things without types, but I don't really see what's so bad about it.  We're not talking implicit conversions or anything like variant types. 


    Oh I realise that's coming, and it has to be there for LINQ, but I really really HATE IT.

    Because you have to assume the interfered type is going to be correct, heck why not just go down the whole late binding route? Tongue Out

    Sure you can override it, and you're hardly likely to be running LINQ queries over a factory pattern or an interface declared object but, oh it just seems so so wrong.

  • User profile image
    blowdart

    wacko wrote:
    One thing I would like to see come to c# is late binding which you can do but it requires far more work then that of vb.net. I mean

    Var x = 1;

    x = "hello";

    that just doesn't work and to me that seems lacking, it would be nice at runtime If could define what x was but sadly that is not a feature of the c# lang.


    HERETIC! BURN HIM! BURN HIM!

    In all seriousness (and I'm just about to dash to the airport), why do you feel late binding is necessary? Especially defining at runtime?

Conversation locked

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