Coffeehouse Thread

30 posts

What is the worst thing in .NET?

Back to Forum: Coffeehouse
  • Klaus Enevoldsen

    .NET Framework is the best, but a few things could be better, right? Tongue Out

    What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!

    In Visual Basic one of the things I don't like is that you can call a function without using () after the method name: Return Me.ToString -> Should be: Return Me.ToString() !!!

    /Klaus Enevoldsen

  • Massif

    Klaus Enevoldsen wrote:
    .NET Framework is the best, but a few things could be better, right?

    What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!

    In Visual Basic one of the things I don't like is that you can call a function without using () after the method name: Return Me.ToString -> Should be: Return Me.ToString() !!!

    /Klaus Enevoldsen


    I'm sure I've had to use .Equals for COM interop. (Exposing a .NET assembly through COM)

    But I can't remember why on earth I had to do that.

  • Lee_Dale

    The Visual Basic thing is a language difference nothing to do with the Framework really.

    I can't really fault .Net I love it I just wish it was platform independent. Also theres a few silly unimportant things that could be changed like having String and string in C# Tongue Out

    One other thing is how easy it is to write things badly, it could be seen as a good thing that an application can be throw together with no real thought but I don't think so, and this is easier to do that other frameworks I think not really sure.  I think the Framework should force some good patterns & practices more if it could. 




  • bgmacaw

    My beef with it is that you can't compile your app and keep your code secure. Anybody can decompile your code with tools provided by MS. Obsfucation, as it currently works, isn't the best solution to this problem because it is a serious pain to work with. It needs to be directly and tightly integrated into the Framework along with application encryption and licensing algorithms for even more security if desired.

  • MasterPi

    The fact that it's called .NET. Tongue Out

  • littleguru

    Klaus Enevoldsen wrote:
    What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!


    Please not! I need Equals:

    int i = 1;
    int j = 1;
    object o1 = i;
    object o2 = j;

    bool r1 = (o1 == o2); // false
    bool r2 = o1.Equals(o2); // true

  • stevo_

    string.Equals has overloads for case insensitive comparisons too..

  • Sven Groot

    As Littleguru's example indicates, the big difference between Equals and operator== is that Equals is a virtual method. You can use it without knowing the actual type of the object. Operator== only works if the variable is the correct type. Many algorithms, such as Array.Sort, take advantage of this fact.

    Furthermore, operator overloading is not a CLS feature, and not all CLR languages support it.

  • VB Man

    bgmacaw wrote:
    My beef with it is that you can't compile your app and keep your code secure. Anybody can decompile your code with tools provided by MS. Obsfucation, as it currently works, isn't the best solution to this problem because it is a serious pain to work with. It needs to be directly and tightly integrated into the Framework along with application encryption and licensing algorithms for even more security if desired.


    Yes. I am with you on that one. I don't like the fact that any old Joe can drop my application in Reflector and view the source-code.

    [C]

  • littleguru

    VB Man wrote:
    
    bgmacaw wrote:
    My beef with it is that you can't compile your app and keep your code secure. Anybody can decompile your code with tools provided by MS. Obsfucation, as it currently works, isn't the best solution to this problem because it is a serious pain to work with. It needs to be directly and tightly integrated into the Framework along with application encryption and licensing algorithms for even more security if desired.


    Yes. I am with you on that one. I don't like the fact that any old Joe can drop my application in Reflector and view the source-code.




    Well on the other hand without it we won't have reflection and IL code at all... Runtime code injection would also be a lot harder... Don't take the fun parts away!

  • odujosh

    System.IO stream classes could be a lot more user friendly. Often times I think they should rewrite them.

    System.IO.Easy

    IO for the mere mortal. I would complain about System.XML as it is as easy a target. But XLINQ fixes the issue for me.

    In fact Brad Abrams comments on this in the Framework Design Guidelines. They did usability testing after it was released. 
     

  • littleguru

    odujosh wrote:
    System.IO stream classes could be a lot more user friendly. Often times I think they should rewrite them.


    What's so complex about it?

    odujosh wrote:

    I would complain about System.XML as it is as easy a target.


    Where are the problems there?

    Note: I'm only trying to understand as I find them very easy to use.

  • Johnny​Awesome

    I always try and use object methods over logical operators, ever since I found out that there is a difference between "" and string.Empty.

    But, I am not sure if that is a "better practice" or not. Or is it just like your preference for String over string?



  • amotif

    My gripes, at least those that come to mind at the moment:

    • Unsigned integers aren't full citizens--they aren't CLS-compliant.
    • The bifurcation between value types and reference types still drives me nuts.
  • Bas

    I wonder, is it faster to test for string.length > 0 or to test for string.empty?

  • littleguru

    amotif wrote:
    
    evildictaitor wrote:
    String.Empty is not extracted because it is not a string literal, wheras "" is extracted, and this means that our translation team would have to translate a hundred blank strings which wastes their time, our time and serves no real purpose. String.Empty implies that the string is intentionally left empty also.


    To what would they translate the literal ""? Could your tool simply not extract empty strings?


    I thought the same...

  • Eric Falsken

    Partial classes and extender methods are a start. now let's get some serious multiple inheritance. Pleeeeeese. I've had to subclass some poorly written parent classes that I had no control over....

  • Eric Falsken

    littleguru wrote:
    
    Klaus Enevoldsen wrote:
    What about ".Equals(object) : boolean"? It is seriously the worst thing in the .NET Framework. It was only invented because we did not have operator overloading in .NET 1.0! Removing "Equals" from the framework would be an OK breaking change!


    Please not! I need Equals:

    int i = 1;
    int j = 1;
    object o1 = i;
    object o2 = j;

    bool r1 = (o1 == o2); // false
    bool r2 = o1.Equals(o2); // true



    how about:

    bool r1 = (o1 == o2); //true
    bool r2 = (o1 === o2); //false

    That would be much better imho. Just like PHP. use === for identity equality, == for value equality, and = for assignment. Very standard and clear.

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.