The real solution is to take away the sealed keyword. Then you can subclass and add whatever you want. Extension methods just confuse things, imo.
Extension methods were added primarily for LINQ. LINQ requires that certain methods are available on all types that implement IEnumerable<T> or IQueryable<T>. Just subclassing doesn't solve that problem, as every pre-existing list type would have to be subclassed to support LINQ in that case. And since C# doesn't support multiple inheritance, an implementation would have to written for all of them.
Similarly, would deriving from the String class allow you to do "foo".SomeMethod()? No, because string literals still aren't an instance of that class. Same if you want to use the method on an object retrieved from another source (e.g. a method in third-party code returning an instance) which wouldn't be an instance of your derived class.
Extension methods solve a different problem than derived classes. And the sealed keyword exists for good reason: some things just aren't suitable to be extension points.
You're right Charles. I realize now that I was thinking about partial classes, not extension methods. I retract my previous statement. And I should have been more clear about all of this as things that MIGHT be coming in the standard at some point. Never mind. Nothing to see here.
Then maybe a modification to the extension class idea can be to allow something like this:
if (this == null) ...
...to do what you describe. In that case the NullReferenceException will not be thrown when calling the extension method itself, but when actually trying to use "this" either explicitly or implicitly (like calling a non-static method etc).
is there any talk within Microsoft to have its own native programming language? I guess, kind of like Apple has Objective-C. A C like language with built in behavior that makes sure handles are closed and memory deallocated. Can call managed code, WinRT and COM. Easily handle ANSI and Unicode strings. Maybe I am describing C++, but without all the stuff that makes the language hard for me to understand.
Not that I've seen. Most programmers are either happy using the C/C++/ManagedC++ that they have, or have chosen to go for a managed language. I'm not sure adding a new native language to the mix would have any momentum at Microsoft or with developers.
You can also just have modifiable classes like many dynamic languages have. That lets you do extension methods and a lot of other metaprogramming type things.
* A C like language Check
* makes sure handles are closed and memory deallocated. Check.
* Can call managed code, Check
* WinRT Check
* and COM Check
* Easily handle ANSI and Unicode strings. Check.
I think instead of spending resources on creating a whole new language, it might be more beneficial to spend those resources focusing on fixing areas of .Net/C# that cause people to want to use something else.
I imaging most of the time it is because .Net is too "slow"? IIRC, tests show it is within 10% of C++'s performance. I'm sure in some areas it is significantly slower, like say when doing DSP. If you look at the IL of .Net code, it is already in a pretty optimized state but it really depends on how the JIT compiles it. I wonder how much performance can be gained by improving the JIT. Maybe have a AOT (ahead of time) compiler that is more agressive and does more optimizations etc.
Oh and much more aggressive method inlining...
C++ is the native language of choice at Microsoft (and C for low level kernel stuff). For Metro, we have a small C++ extension, C++/CX. For GPGPU programming, we have a small C++ extension, C++ AMP.
I don't see why open classes can't work for static/native languages by the way. Some people really think open classes it's a SUPAR BAD idea, but I never seen any argument on why.
(Open classes means you can "reopen" any class, eg std::string, and add features to it. Similar to BitFlipper's idea.)