8 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Sven F. commented  ·  January 16, 2013 5:38 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• Qwertie commented  ·  September 24, 2012 10:48 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  +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 Dotson commented  ·  May 10, 2012 8:46 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• Ron commented  ·  April 11, 2012 11:09 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Hollberg commented  ·  October 20, 2011 11:47 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• Andrew Teebay commented  ·  August 20, 2011 7:00 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I too would like to see this but even more I would like to see extension Properties also

• Rune Juhl-Petersen commented  ·  August 1, 2011 4:10 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• mabster commented  ·  July 31, 2011 10:37 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I blogged about this a while back, with an example syntax: http://madprops.org/blog/static-extension-methods/ I agree it'd be nice.