I suggest you ...

C# support static extension methods like f#

C# support static extension methods like f#

504 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Márcio AlthmannMárcio Althmann shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    10 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Julius KunzeJulius Kunze commented  ·   ·  Flag as inappropriate

        This article was created a long time ago:

        http://stackoverflow.com/questions/4909156/why-arent-c-sharp-static-class-extension-methods-supported?lq=1

        I don't like the word 'feature' in this article - because it is just a completion of the super successful extension method concept that was not implemented completely when in was introduced ("the schedule was full")!

        Come on, Visual Studio team! There are so many votes for a relatively simple language rounding off and there is still no response/consequence? You do great things - please bring them to an end!

      • Mike MarynowskiMike Marynowski commented  ·   ·  Flag as inappropriate

        +1 to Matt Dotson's comment...so simple and logical, I can't believe it wasn't included at the same time that extension methods were introduced!

      • Sven F.Sven F. commented  ·   ·  Flag as inappropriate

        Here is a possible solution to static extension methods. It does not apply to all needs, but may be convenient for some cases.

        To extend classes (which are defined in external libraries) with static methods just use inheritance and name the class the same as the original, but use your own namespace which will be favored by the compiler.

        Example: I wanted to extend value conversion for XML with object handling. This is what I did:

        namespace MyNamespace
        {

        public class XmlConvert : System.Xml.XmlConvert
        {
        public static string ToString(object value) {...}
        public static object Parse(string value, System.Type targetType) {...}
        }

        }

        Now when I use "XmlConvert" it will point to the newly defined class but will still show all the static methods of the original System.Xml.XmlConvert.

      • QwertieQwertie commented  ·   ·  Flag as inappropriate

        +1 to Matt Dotson, no syntax changes are needed. Currently I have a namespace called "Loyc.Math" and it is constantly conflicting with the System.Math class... ugh. So the C# team has the opportunity to solve multiple problems at once here.

        All the compiler has to do is

        (1) ignore static classes in new expressions (e.g. "new String(...)" should ignore a static class called String if there is one)

        (2) allow lookup in multiple classes at the same time (but do a separate overload resolution on each class -- if an overload matches in multiple classes it should be an error, lest someone should introduce a new static class and accidentally change the meaning of existing code by adding a better-matching overload.)

      • Matt DotsonMatt Dotson commented  ·   ·  Flag as inappropriate

        You don't even need to change the syntax!! You just need to make the compiler a little smarter. Make the compiler resolve ambiguous type errors by matching the method signature. If the two types have a matching method with the exact same signature, then make a compiler error, but you have enough info to resolve the right type in 99% of the cases.

        namespace MyExtensions
        {
        public static class Math
        {
        public static int SomeMethod(int x)
        {
        return 0;
        }
        }
        }

        namespace Sample
        {
        using System;
        using MyExtensions;

        public class Foo
        {
        public void Bar()
        {
        var x = Math.SomeMethod(5); // <<<< Currently an ambiguous type error.
        }
        }
        }

      • RonRon commented  ·   ·  Flag as inappropriate

        I was inspired by mabster's blog post. Here is my proposed syntax for static extension methods (on types), static extension properties (on types), and extension properties.

        // type extension method
        // Pro: goes well with existing extension method
        // Pro: goes well with proposed type extension property syntax
        // Con: is a weird parameter syntax that is not really a parameter
        public static int Foo3(static SomeStaticClass) { return 0; }

        // type extension property
        // Pro: goes well with existing extension method syntax
        // Pro: goes well with proposed method-style type extension method
        // Con: it makes a property look like a method; might be confusing for new users.
        public static int Foo4(static SomeStaticClass) { get { return 0; } }

        // instance extension property
        // Pro: goes well with existing extension method
        // Con: it makes a property look like a method; might be confusing for new users.
        public static int Foo5(this SomeClass c) { get { return 0; } }

      • RJ HollbergRJ Hollberg commented  ·   ·  Flag as inappropriate

        I would love this! Static extension methods, extension properties, and static extension properties. And while you're at it, throw 'em in VB.NET too ...

      • Rune Juhl-PetersenRune Juhl-Petersen commented  ·   ·  Flag as inappropriate

        This is a great idea. This idea is not new but lets hope someone reconsiders this. As F# supports this, then ofcourse C# should as well.

        I have been mising this a lot to create object factories in a better way.
        Consider defining a new() method on an Interface: ISomeInterface.new().
        Or get(id) to retrieve from database. ISomeInterface.get(id).

        Just like instance extension methods, this is just syntax sugar, but in the end your have some code that is much tidier.

      Feedback and Knowledge Base