C# Extension method doesn't fit in this scenerio?
-
J4amieC wrote:
myList.Sort("myField DESC") and it shows up in intellisense.
Yes. because "myList" is an object. For example: I have an extension method like that.
namespace SilverlightHelpers.Helpers {
//Silverlight - Array Class: http://msdn.microsoft.com/en-us/library/system.array\_members(VS.95).aspx
//.NET - Array Class: http://msdn.microsoft.com/en-us/library/system.array\_members.aspx
public static class ArrayHelper {
public static T Find(this Array ary,
T[] array,
Predicate match) {foreach (var o in array) { if (match(o)) { return o; } } return default(T); }}
}if I use like Array.Find, it won't work. but if I use like
Point[] points = { new Point(100, 200),
new Point(150, 250), new Point(250, 375),
new Point(275, 395), new Point(295, 450) };points.Find << It will work.
Please correct me if I'm wrong..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
right, you cant add static extension methods AFAIK (of course all extension methods themselves are static, but you cant add a static extension method to a class). So your only option is MyArrayHelper.Find
J4amieC wrote:
So your only option is MyArrayHelper.Find
Yes. I used that way in my project[^] now.. that's big problem in porting WPF to SL. :( I need to change all Array.Find to ArrayHelper.Array.. The same goes for Enum.GetValue too.. I had to use EnumHelper.GetValue. or I have to use Linq for that..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
Create a new class derive from Array. Then add a public method "Find" in it. Then you will see the method "Find" in Intellisense.
-
J4amieC wrote:
So your only option is MyArrayHelper.Find
Yes. I used that way in my project[^] now.. that's big problem in porting WPF to SL. :( I need to change all Array.Find to ArrayHelper.Array.. The same goes for Enum.GetValue too.. I had to use EnumHelper.GetValue. or I have to use Linq for that..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
Michael Sync wrote:
I need to change all Array.Find to ArrayHelper.Array..
Make a wrapper method, and use that all over, then only 1 place to call the helper.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
Michael Sync wrote:
I need to change all Array.Find to ArrayHelper.Array..
Make a wrapper method, and use that all over, then only 1 place to call the helper.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008)leppie wrote:
Make a wrapper method, and use that all over, then only 1 place to call the helper.
You mean like that.
public static class Array{
public static ... Find(..){
///.. my own implementation
}
public static ... Remove(...){
///.. call the original one.
System.Array.Remove(....);
}}
Is this like that? but I think the name will be conflict. (My Helper.Array and System.Array) And I can't remove "using System;" since there are a lot of other references..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
leppie wrote:
Make a wrapper method, and use that all over, then only 1 place to call the helper.
You mean like that.
public static class Array{
public static ... Find(..){
///.. my own implementation
}
public static ... Remove(...){
///.. call the original one.
System.Array.Remove(....);
}}
Is this like that? but I think the name will be conflict. (My Helper.Array and System.Array) And I can't remove "using System;" since there are a lot of other references..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
Put your array class in the root namespace of your project. That way, it will be used as the default instead by VS. If at anytime you need the built in class just specify System.Array
Dave
Thanks. That means I dont need to change Array.Find to ArrayHelper.Find. But I will need to change Array.Remove to System.Array.Remove? Another thing: I think the name will be conflict.
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
Thanks. That means I dont need to change Array.Find to ArrayHelper.Find. But I will need to change Array.Remove to System.Array.Remove? Another thing: I think the name will be conflict.
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
Michael Sync wrote:
But I will need to change Array.Remove to System.Array.Remove
No. For any methods that you need to keep that exist in System.Array - simply create a method in your class with the same return type, name and signature. Then in your method return the System.Array's method result passing the parameters to it.
Michael Sync wrote:
Another thing: I think the name will be conflict.
No, the IDE and compiler will assume yournamespace.class if there is also a System.class with the same class name.
Dave
-
Let's say there is no method called Find in Array class. So, I created my own Find method. then, if I type Array. then I want to show my own method "Find" in intellisense. AFAIK, C# extension method doesn't fit in this scenario so is there any way to make my own method to show in Intellisense? is there such a thing like attached method (similar to attached properties in WPF)?
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
Technically, extension methods require an instance of the data type being extended as the first parameter so you can't create a "true" static method on the actual type. You'll need to continue using a static helper class/method or create an extension method and call it from the instance of the array you want to search for the value.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Put your array class in the root namespace of your project. That way, it will be used as the default instead by VS. If at anytime you need the built in class just specify System.Array
Dave
I'd highly reccommend against doing that. It can and most likely will lead to a lot of maintenance headaches later. It will also make it harder for new developers to get up to speed on the codebase since there is now a "new" Array class that isn't the standard one that everyone is familiar with.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
I'd highly reccommend against doing that. It can and most likely will lead to a lot of maintenance headaches later. It will also make it harder for new developers to get up to speed on the codebase since there is now a "new" Array class that isn't the standard one that everyone is familiar with.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Even though I suggested it, I agree. Personally I would carefully rename all the 'Array' code to my helper class but the OP didn't want to do that. I've only done it the other way once and I made sure I implemented EVERY method/property/interface and all their overloads from the original class to avoid problems. It's been OK so far, but it was a headache creating the class in the first place!
Dave
-
I'd highly reccommend against doing that. It can and most likely will lead to a lot of maintenance headaches later. It will also make it harder for new developers to get up to speed on the codebase since there is now a "new" Array class that isn't the standard one that everyone is familiar with.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Thanks, Scott. It's true that it will lead a lot of maintenance headaches but the problem is that we already have a lot of classes written for WPF project. I'm trying to port them to Silverlight-compatible project. What I was thinking is that if we can use the same way that we used to use for WPF then new developer won't need to remember that we have to use this (e.g ArrayHelper.Find) in Silverlight and we have to use that (ie. Array.Find) in WPF. All he need to do is that just use Array.Find no matter whether he is in Silverlight or WPF..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
Michael Sync wrote:
But I will need to change Array.Remove to System.Array.Remove
No. For any methods that you need to keep that exist in System.Array - simply create a method in your class with the same return type, name and signature. Then in your method return the System.Array's method result passing the parameters to it.
Michael Sync wrote:
Another thing: I think the name will be conflict.
No, the IDE and compiler will assume yournamespace.class if there is also a System.class with the same class name.
Dave
Thanks, Dave. I will try. But Scott's suggestion is also nice one. I will keep the suggestions from both of you and I will mentioned about that to my manager..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
Thanks, Scott. It's true that it will lead a lot of maintenance headaches but the problem is that we already have a lot of classes written for WPF project. I'm trying to port them to Silverlight-compatible project. What I was thinking is that if we can use the same way that we used to use for WPF then new developer won't need to remember that we have to use this (e.g ArrayHelper.Find) in Silverlight and we have to use that (ie. Array.Find) in WPF. All he need to do is that just use Array.Find no matter whether he is in Silverlight or WPF..
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
I understand the problem you are looking at. It's a trade off as either way you are going to end up with possible maintenance issues later.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai