Viv,

Some thoughts (of mine)

I like the runtime-plug-in goodie - although I think that is beyond the original question since the need is known at design time

The static class methods was an idea of Tim. The only thing that makes a method an extension method is this just after the opening parenthesis of a static method
But I see a difference in approach. An extension method always pops up in intellisense whereas I think that calling a method of some static class is more explicit

I do not know which of the 4 methods is the best. We do not know about the whole constellation. And even if we did there would be some debate


I do not think that the only use of extension methods is when you do not have the sources. I think (not tested) you can implement them as well even when you have the sources
Should you use them if you have the sources ? I do not have an answer to that yet

Also possible is to define dummy interface and implement the extension methods on that interface

Do you also have a day off in the UK today ?



>Hi,
>I also find (2) a flexible approach - especially since you can plug in different implementations at runtime etc.
>
>>Not sure yet whether I should make an extension method or a just a static class with those methods
>I think you end up with exactly the same excution when compiled.
>x.MyExtension() translates to
>MyExtension(x) under the hood - you can invoke an extension method in this way if you wish anyway
>
>I don't remember where I read that MS favours minimising their use (and I certainly don't take everything they say as gospel(g)) - but they came up with it and understand the innards so I assume there is some basis to the recommendation. Maybe a performance issue, maybe a perceived readability issue. There's a tendency to think of extensions methods as having fixed (baked-in) behaviour but the potential to have them behave differently in different parts of an app - but I don't think that would be a real concern in a real world situation.....
>
>>About the extension method
>>It has its pros and cons - you can add it to any class, but if you have many - there's the trees and the forest
>>If only that class of grid needs them - better to use #1 imo
>>
>>If all grids need them - better to use an extension method
>>If the grids that will need them do not necessarily have the same base class - an Interface + extension method on the interface may be the way to go
>>
>>Reason why I suggested (2) is that I've started reading the GOF - favour composition over inheritance. Haven't digested yet - but I see some advantages over subclassing
>>Subclassing may lead to huge classes in the end - too much code(if you could see my grid's base class in foxpro - uh) . But (2) has the advantage that the additional class will be small and easy to understand - and maintain. In addition, you just plug it in where you need it.
>>
>>ps: I haven't thought extension methods fully through yet. I could add a lot of extension methods to string. But too many is not good either
>>[Some things like convert to utf8, utf7, zip,. .... Not sure yet whether I should make an extension method or a just a static class with those methods]
>>
>>Just dreaming
>>
>>ps: Who cares about MS recommending against extension methods ? I don't
>>
>>Gregory
>>
>>
>>>Hi,
>>>
>>>I suggested the first. Thought of suggesting the second. But I'm not sure about using an Extension method.
>>>I know it would work but MS seem to recommend against them when there are alternatives.
>>>Great if you don't have access to the source of the targeted class but, in the end, they are really just syntatic sugar?
>>>Best,
>>>Viv
>>>
>>>
>>>>At least three possibilities come to mind
>>>>
>>>>(1) Subclass the grid, and put the methods in that class
>>>>The grids you use will be based on that class
>>>>
>>>>(2) create a class that implements those methods
>>>>Add it to the grids that will use it
>>>>Call the methods of that class
>>>>
>>>>(3) Extension methods
>>>>- either for all grids
>>>>- or for a subclass of the grid's class
>>>>
>>>>
>>>>There will be other ways