views:

60

answers:

2

I was wondering what is the effective weight of extension methods, if used very wildly.

If, for example, i decide to create a lot of string/int/datetime extension methods for many of the common day-to-day tasks, to obtain a kind of fluent interface as a result, it may be that the overall weight would pump up excessively? And if yes, would it be at design time (e.g. intellisense db growing too much) or runtime or both? Or none of them? To avoid a massive amount of intellisense-suggested methods everywhere, i was thinking about putting them inside a separate namespace like "MyCompany.PathExtensions" or "MyCompany.DateTimeExtensions" or even all of them in a fancy "MyCompany.FluentEverywhere" or similiar...

An example of what I'm talking about:

DateTime d;
d = 23.Minutes().FromNow();
d = "14".ToIntOr(0).IsBetween(10,20).IfFalseThrow(new Exception("foo"));

String finalPath;
// This will give you "c:\foo\bar\"
finalPath = "c:\\".AppendPath("foo").AppendPath("bar").EnsureTrailingBackslash();

String finalUrl;
// This will give you "ftp://mycompany.com/foo/bar"
finalPath = "mycompany".EnsureDomainExtensionOr("com").AppendPath("foo/bar").EnsureTrailingSlashNotThere().EnsureProtocolOr("ftp");

And so on... oh, and do not go berserk on things like .IfFalseThrow(...), they were just examples ;) !

What do you think? Apart from the usage, that is likable or not depending on tastes, there may be problems relating overall weight?

Thanks

+3  A: 

what is the effective weight of extension methods

Exactly the same as effect of using static methods. Extensions methods are no more, no less than just static methods wrapped by C# syntax sugar to look like normal methods.

Dmytrii Nagirniak
I know that they are static methods, it's kinda clear when you write them ;) ... but they are not *just* that. In fact the "syntactic sugar" has a cost, at least at design/coding time: intellisense database growing (maybe?) too much, and so on... i tought about discussing about that subject
njy
It only has the cost during compilation, debugging. As every method that you declare. If you want to avoid "overhead", then don't declare anything :). Seriously, it is so misarable that I would even never though to ask about it. Especially when it does not effect performance in production.
Dmytrii Nagirniak
+1  A: 

Intellisense may grind extra fetching the methods, but at runtime you're calling a bunch of statically defined methods, they're very lightweight.

Now some of the Linq extension methods are heavy but that's because they're doing work, not just because they're extension methods.

Like you said, it's all a matter of preference with the look/chainability, etc...but for performance, there's nothing added by using an extension method for something.

Nick Craver
Thanks Nick, in fact apart from code time i did suspect there were not that much at runtime, but would like to be sure about that, discussing a little bit.
njy