You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: Some IDEs like Rider are now showing a lot more extension methods in IntelliSense, even those, that are not imported in the current file. On the one side this makes it much easier to use them on the other side it causes the IDE to potentially overwhelm the developer with the amount of suggestions.
This will only get worse with dotnet 6 and C# 10 with global using directives, where you might not even be able to see which extensions are displayed because of a global or local using.
Suggested Solution: To prevent intellisense pollution there should be a more deliberate choice which methods, especially variants of "return" methods are actually provided as extension Methods and which only as normal static methods, usable with static imports to have more control over when these methods are found by current IDEs.
The text was updated successfully, but these errors were encountered:
Tho I like the pipe operator (I love it in F#) for it‘s obvious reasons, it‘s not helping with reducing suggestions through the IDE. In order for the IDE to suggest less methods, they can‘t be extension methods. So, they would need to be reworked anyways to be just static function. Of cause they then could be used with a pipelining operator like in F#. But that‘s a whole other discussion of why then not just using F# after all.
to all of that Bind() is basically your Pipe(). You can simply chain methods returning monads together. But there is an even cooler thing to approach the railway oriented style of pipe. Use LINQ query syntax:
Problem: Some IDEs like Rider are now showing a lot more extension methods in IntelliSense, even those, that are not imported in the current file. On the one side this makes it much easier to use them on the other side it causes the IDE to potentially overwhelm the developer with the amount of suggestions.
This will only get worse with dotnet 6 and C# 10 with global using directives, where you might not even be able to see which extensions are displayed because of a global or local using.
Suggested Solution: To prevent intellisense pollution there should be a more deliberate choice which methods, especially variants of "return" methods are actually provided as extension Methods and which only as normal static methods, usable with static imports to have more control over when these methods are found by current IDEs.
The text was updated successfully, but these errors were encountered: