What would be happen if all static methods would be extension method default ?

Question

Hello everybody

Static methods always should to encapsulate arguments by parenthesis . So it is much more easy to use extension methods while typing. That is one of the reason why i like extension methods.

I am not sure when time it is better to use extension or static methods. And i am thinking that what would be happen if all static methods would be default extension methods. Would be easy typing for extension methods but what other advantage or disadvantage of this idea ?

Edit

After i realize that not good idea to make all static methods to extension methods. For example : Methods that does not take argument or takes argument of different type. Also we can change the question. What would be happen if static methods would be usable by extension methods default for static methods which takes argument of its own type.

Answer 1

Extension methods apply to instances of objects while static methods apply to types themselves. Static methods provide factory or utility functionality while extension methods add semantic value to specific objects.

For example, take Process.Start(ProcessStartInfo): it is a static method that gets called on the Process type. It would be weird for it to be an extension method since you'd have to create an instance of Process before actually calling it (note: yes there is a Process.Start method that operates on instances, but it is assumed that the Process object already has its start information populated).

If you want to extend the functionality of instances of a type and you can't change the original source, extension methods make sense. If you want to have static utility functions that are closely related to your type, static methods make sense. They each have their uses.

Answer 2

All extension methods are static methods.. The difference is that in an extension method, the first parameter in the method's signature must include the this keyword to indicate what type the method is an extension for... In a sense, the method is static to the type it is defined in, but, (as Chris mentions in his answer), they are non-static (instance) to the type defined in the first parameter...

If all static methods were extension by default, what would you do about old code that doesn't have the thgis keywpord? and how would the compiler know what type to 'attach' the extension method to?

Answer 3

While many static methods, especially for value types and strings, operate on instances of themselves, there are static methods for which the extension syntax would not make sense because they do not act on their own type. ConfigurationManager, for example, is a "pure static" that has no instance component; it makes no sense to attempt to structure any such call as an extension method.

I have also gotten into situations where I had references to duplicate extension methods in different utility libraries with similar signatures; referring to the static class containing the method is the only way to resolve such ambiguities without a big refactor.

Lastly, extension methods are great in moderation. However, my current project has become perhaps a little too "fluent"; we have extension method wrappers for most of the String statics such as IsNullOrEmpty() and Format(), as well as parsing extension methods for every value type (wrappers for int.Parse, byte.Parse, DateTime.Parse, etc) and variations (such as TryParses, IsNullOrBlank, IsNotNullOrEmpty, etc.). There are a LOT of things you can do to a string instance, and in our project, most of them can be tacked on to the end of that instance (even a literal). That slows VS down considerably when you hit that period, and increases its memory footprint (and that of ReSharper, which provides IntelliSense extensions and using/reference suggestions).

Answer 4

For one thing, there would be massive ambiguity when it comes to int.Parse(string), double.Parse(string), etc. all wanting to become extension methods on string at the same time. It's an important design decision as to whether the method should logically be extending the functionality of the operated-upon type, rather than being logically associated with the type defining the static method.