Extending existing classes

One other point that came up in the static import thread was extending existing classes. It's not uncommon to want to add specific methods to existing classes - or at least have the appearance of doing this. For example, I might want to add a new method to the string class, so I can call it with:

string s = ...;

string r = s.Permute(10, 15);

rather than

string r = Utils.Permute(s, 10, 15);

We've discussed this a few times in the past, and we think this is an important scenario to consider. There are a number of reasons why you wouldn't want to actually modify the class, of which security is just one consideration. But one could think of a way of writing something like (very hypothetical syntax):

class Utils
    public static string Permute(string s, int a, int b) {...}

and have the compiler then allow you to use it as if it were part of the string class. This is very useful, but perhaps not terribly understandable, and would certainly be open to abuse.

Another option would be to allow the following definition (also hypothetical)

class MyString<T>: T where T:string
    public string Permute(int a, int b) {...}

Now, if you use a MyString, you can add methods onto the existing method. This would also be useful to add a specific implementation of something onto an existing class, somewhat in the way that Mixins work.

We have no plans in this area, but will likely discuss the scenario more in the future.

Comments (15)

  1. Adam says:

    My opinion is if you are going to do something like this to C#, you use prototypes like you have in Javascript, JScript.NET, etc.

    (I’m sure you know what I mean, in case someone reading this doesn’t)

    function MyClass_MyFunction() {


    function MyClass() {


    MyClass.prototype.MyFunction = MyClass_MyFunction;

    new MyClass().MyFunction()

  2. Fabrice says:

    Sounds a bit like Delphi’s class helpers.

  3. zwetan says:

    I totally agree use something as the prototype in ECMAscript

    this concept is very powerfull and it’s THE reason I’m still doing ASP+JScript and I didn’t move fully to ASP.NET+JScript.NET

    think also to another scenario:

    me as a programmer or service provider I give a compiled DLL and not a source code

    for my customer point of view being able to add features with mixin could be a powerfull feature

    I understand that the abuse could be a turn off for that kind of feature, but look also at the pass with all the different String class

    you could found in C++

    String2, StringUtil, etc…

    is not good naming convention imho

    being able to extend existing class, even if it could be abused, would also allow to keep

    namespace well named and clean

    just my 0.2 euros 😉

  4. Doug McClean says:

    I think we should be more open to static helper methods like that. I find that they make interfaces much more useful.

    For example, almost all of the new methods on List<T> that take delegates as arguments and perform common list operations can be defined in terms of the IList<T> interface, except that there is nowhere to put them because:

    a) if they go in the interface, every implementer of that interface has to provide an implementation, even though almost all or all of those implementations will or should be the same because the behavior is defined in terms of the existing interface members

    b) C# doesn’t allow static members on interfaces (although to my understanding the CLR does)

    c) if they are defined on a helper class, discoverability becomes a problem

    In this spefic case, I suggest that we make static versions of all those methods on List<T> or some other class in the System.Collections.Generic namespace that take an IList<T> as an argument, but a more general solution is highly desirable since there are a number of related problems.

  5. Darren Oakey says:

    I really like the idea of being able to add methods to existing classes. A friend of mine had an argument with Stroustrup about it in the C++ world – he always (and unsuccessfully) wanted it added.

    as far as syntax goes, how’s this for an idea?

    extender class StringHelper : String


    public bool Contains( string subString )

    {return Instr( subString)> -1;}

    public static string FairlyUnique( int length)


    return Guid.NewGuid().ToString().Substring( 1, length );



    Allowing many extenders to exist for a particular class, and giving extenders only public access to the class they are extending.

    This would brilliantly gel with other requests – like it would get rid of the need to add static functions to interfaces for instance – because you could then do this:

    public interface IPreferencesStorage



    extender class IPreferencesStorageFactory : IPreferencesStorage


    public IPreferencesStorage CreateFromConfiguration( SystemConfiguration config )


    return (config.UseRegistryForPreferences)

    ? new RegistryPreferenceStorage()

    : new FilePreferenceStorage();



    And then you just have to get to have code like

    IPreferencesStorage storage = IPreferencesStorage.CreateFromConfiguration( currentSystemConfiguration );

  6. Lostinet says:


    I think this is just a code game..

    Here is my option:

    public codegame class StringHelper : string//even the string class is sealed


    //no fields

    //will compile into static public string CodeGameLeft(string codegametarget,int len)

    public string Left(int len)


    return Substring(0,len);


    public string SafeLeft(int len)



    return this;

    return Substring(0,len);



    and call it just like:

    string s="hello world!";

    StringHelper sh=s;//implicit..

    string l1=s.Left(3);

    string l2=((StringHelper)s).Left(4);

    and it just means :

    string s="hello world!";

    string l1=StringHelper.CodeGameLeft(s,3);

    string l2=StringHelper.CodeGameLeft(s,4);

    of cause it’s would be nice if this syntax is ok:

    string l3=s<StringHelper>.Left(5);

  7. Colin says:

    I’d say that although it sounds nice to be able to add methods to existing classes, it would probably be a bad idea (putting on my maintenance and code readability hat). That said it would be nice to have a different kind of "inheritance" that allows a "public-only" view of the base class. That means that it is entirely clear which class the additional methods belong to. Cases where this would be useful would be ado.net, where db vendors create sealed class implementations of Connection and DataReader classes.

    When trying to extend these classes you need to make a clunky wrapper class that implements the interfaces, when you just want to add 1 or 2 methods to them.

  8. Dion Almaer says:

    Anything that gets you to the world of mixins would be a win.

    This is a great way to get around multiple inheritence hell, yet use functionality nicely.

    I also like having the ability to be able to have an interface, and put default behaviour in that interface. It is just nice and clean and I find it a lot cleaner compared to having a million files with factories etc.

  9. damien morton says:

    Doug McClean’s comments on the new List<T> methods is correct. Most of those methods would best be attached to IList<T>, and many of them should in fact be attached to IEnumerable<T> (i.e. the ones that dont rely on an indexer).

    I dont think that adding methods to classes is the right way to go.

    Interfaces with default methods might be the way to go, but.. it seems to break the basic model of what an interface is.

    Static helper methods (and operators) in an interface is more like what we are looking for.

    Maybe whats needed is true multimethods.

  10. Thong Nguyen says:

    This feature is a long time coming but I would prefer the following syntax:

    public class StringExtensions : static string


    public String Left(int count)


    return this.Substring(0, count);



    The "static" can be used to signify the class is extending sidways.

  11. Topce says:


    C# becomes type safe Ruby

  12. I want to play too 😉

    We’re not talking about just extending a sealed class like string, here.

    Here’s a scenario that we have in ASP.NET:

    Some third party control editor wants to implement a universal pagination system (like the one in ASP.NET v2 beta 1), and for that he needs to add a few properties and methods to the base Control class (like ControlPager, CurrentPage, etc.). It is necessary to do it on the base class and not on something that derives from Control, because we want every existing control to automatically get the new members.

    What Microsoft does to implement that is very simple: we just add the new members to the base class (breaking a few existing controls at compile time along the way).

    But a third party just couldn’t do it.

    Except if they could write:

    public new class PaginatedControl : System.Web.UI.Control {

    // … new member implementations


    The Control class would behave as usual for old code, but new code could explicitly cast to PaginatedControl and use the new members.

    Of course, that would have to be associated with a new set of permissions as this could lead to dangerous code (although if explicit casting is necessary to call the new members, I don’t really see a valid scenario as only new code (which is aware of the new class) can see them, but I may be wrong on this)

  13. Art Gilbert says:

    This concept is new enough, at least to me, to be open to consideration despite a couple of obvious liabilities.

    From an object oriented design perspective the questions revolve arround the relationship of the operation to the type of thing upon which the operation is performed. In the original example, a permutation function that does not belong to any class can act upon a string without violating the nature of what it means to be a string. Adding the permutation function to the string will necesssarily raise the question, is Permutation consistent with the concept of a string type? Since we may permute numbers as well as strings, does that imply that a string is a number? I realize that this is pretty thin but this sort of confusion is the most common cause of "bad" code. A mis-diagnosed problem yields a solution that is "good enough" for the moment but quickly breaks when attempting to extend the solution to a similar problem.

    First ask, what is the problem being solved? If you are capable of adding any behaviour to a class, without consideration for the nature of the class, you stand a good chance of introducing confusion, not clarity. E.g., you can add the behaviour of flying to a human being without changing the human into a bird, airplane or Icarus resulting in utter confusion. Such a development would not be progress. On the other hand, you can hobbies, abilities and preferences to a human and be coherent. And the abilitiy to add such properties and behaviours is certainly preferable to defining a new derived class of type cook, athlete or programmer.

    The potential good that can come from such a feature is the complete abstraction of common features into discrete functors that may be applied to a wide variety of types that cannot be readily predicted prior to development. The potential evil is a level of spaghetti code that would make mangled C++ code look like an elegant algorithm worthy of Knuth.

Skip to main content