no final decision made, but currently i would use extension methods to extend e.g. gui classes, but not to add functionality to types like string, int etc. Ok, in .net everything is an object, but maybe i´m too old and worked too long with the VO mixture of objects and pure funcs
I do not have a strong preference, but since the score goes too high and I usually support the losing team , I'll mention that I usually prefer using a static method of a "Funcs" class (yes, similarly to what an extension method is under the hood) for that, because sometimes when I read some code that calls an (extension) method that I am not aware of, I am left wondering what that is.
I prefer things to be obvious how they are working, rather than being hidden behind implementation details, so I usually avoid extension methods. I understand they are also a nice thing, too, though, so I am not against using them either.
that i see similiar, as long as you "extend" "your" class - but then, why not write the functionality as part of the class directly.
Wolfgang adds to existing, i.e. , "system classes/types" - here i'm with Chris, usually one knows more or less what to expect from e.g. a string object - and has to wonder, why on earth now there's new functionality; and not to forget: "where" is the definition?
Nothing really wrong with this, but make it a 3.5:2.25
this results in left to right vs. right to left reading - to "like" is neither.
If i' d need that more than once, i'd write an access or a func, properly named
See my request to Robert for a switch to access Dataserverfields "cleaned"...