I suggest you ...

Move all extension methods into separate namespace(s)

When writing code that uses ServiceStack, its fairly common to import the ServiceStack namespace (or others) via a using statement. Doing so will make all the extension methods within that namespace available.

I have experienced several cases where I have my own custom extension methods with a conflicting signature that I would like to use instead of the ServiceStack method. However there is no ideal way to disambiguate them currently. My only choices are:

1) Move code around into separate files so that I only import either the ServiceStack namespace or my namespace.

2) Refer to the proper method by including the name of the static class, and not using the extension method syntax.
Example:
var message = "Hello, {0}".FormatWith("World");

would become:
var message = MyCustomNamespace.StringExtensions.FormatWith("Hello, {0}", "World");

My suggestion is to move all your extension methods into separate namespaces that follows a consistent pattern.
If they are in "ServiceStack" they are now found in "ServiceStack.Extended". Or if "ServiceStack.Text" then "SericeStack.Text.Extended", etc. I'm not suggesting moving them to a separate dll.

Thanks,
Casey

References:
"The call is ambiguous"
https://stackoverflow.com/questions/5283583/extension-methods-conflict

"Put extension methods into their own namespace"
https://blogs.msdn.microsoft.com/vbteam/2007/03/10/extension-methods-best-practices-extension-methods-part-6/

1 vote
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Casey shared this idea  ·   ·  Admin →
    declined  ·  AdminDemis J Bellot (Developer, ServiceStack) responded  · 

    That’s the opposite of how ServiceStack is designed, hurts discoverability, increases the friction and support burden due to broken references and would result in unacceptable breaking changes. The only extension methods we plan on removing are those duplicated by newer versions of the .NET Framework.

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Casey commented  · 

        Demis,

        Thank you very much for taking the time to explain this to me. It helps to see the history, and to know that you've tried this already, and have given it a great deal of thought.

        As a bit of context, I use ReSharper and I never have any problems finding extension methods, but I could see that being a problem for those who don't.

        Extension methods are probably my favorite language feature of C#, and I certainly appreciate the development experience with them.

        I am complete on this topic. Thank you.

      • AdminDemis J Bellot (Developer, ServiceStack) commented  · 

        We used to hide extension methods behind custom namespaces in v3, it created a terrible dev experience, with frequent reported issues on not from being able to find API, broken refs, bloated namespaces, etc.

        HTTP Utils and OrmLite are examples of extension methods on built-in APIs which provide a much nicer dev experience because their extension methods on built-in types, it enables a cleaner, leaner, more readable/reusable/composable functionality with minimal abstraction/dependencies, etc. These APIs would be nowhere near as pleasant to use if they were tacked on an artificial abstraction instead. ServiceStack leverages the utility of extension methods pervasively throughout out its code-base because of these attributes.

        We've already experienced the ugliness of hiding extension methods in custom namespaces, v3 code base is more verbose and had poorer discoverability as a result. Whilst we're careful about which extension methods we add on string/object/etc, we add them when APIs are generic and useful. When it makes sense to we'll add them on a custom namespace so they light up when you're working in that domain, e.g. ServiceStack.OrmLite, ServiceStack.IO but otherwise general purpose utils belong in the base ServiceStack namespace where they can be found.

        Extension methods are one of C#'s greatest language features to enable a simpler, leaner, more readable and productive dev UX. We use them extensively when they add value or when we believe .NET has missing APIs on their built-in types. Our approach continues to serve us well and has had very few complaints because of this (I can't remember the last time this was reported as an issue).

        Unfortunately .Fmt() and FormatWith() were added to make up for the lack of string interpolation in C#, they wouldn't exist if C# had implemented it much earlier. I may consider moving FormatWith() in a ServiceStack.Legacy namespace in v5.

      • Casey commented  · 

        I understand about the breaking changes.

        For any new work, where your time and energy are already being spent on a new direction..., I'm hoping you consider this concern for extension methods on types that you don't own, such as System.String.

        Thanks.

      Feedback and Knowledge Base