Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Common methods for different objects
Message
From
21/05/2009 05:29:07
 
 
To
21/05/2009 05:15:53
General information
Forum:
ASP.NET
Category:
Coding, syntax and commands
Environment versions
Environment:
C# 3.0
OS:
Windows XP
Network:
Windows 2003 Server
Database:
MS SQL Server
Miscellaneous
Thread ID:
01400964
Message ID:
01401213
Views:
50
>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

That's a good point - having intellisense on extension methods is definitely a plus.
>
>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

Agree with all.

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

No (well I might take one but it's not a general holiday). Monday however is.

>
>
>
>>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform