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
With the current extension method mechanism (the old feature), there can (under certain circumstances) be multiple candidate extension methods. The compiler chooses the candidate extension method from the nearest namespace (forgive my utterly imprecise description).
This basically enables (for example, a source generator) to “intercept” (wrong term) and replace one extension method with another at build time. This is only possible if the extension method is called as an extension
[1] obj.ExtensionMethod();
and not if it is called as a static method
[2] MyExtensionClass.ExtensionMethod(obj);
Such a method can also not be intercepted by an interceptor (because it is static / correct me if this is also subject to change).
In the [1] case, a source generator could generate a new extension method in a namespace closer to the current namespace than the original extension method. This new method will then be selected by the compiler.
Disclaimer: I wouldn’t consider “replacing one extension method with another at compile time” a fabulous design choice. I am also a bit uncertain whether I like the rules how the compiler selects the extension method in the current version of the feature (understanding there is little to do it better). However, under certain circumstances, the option to replace/redirect an extension method or the ability to use an interceptor may be beneficial (scenario: modifying implementation types in registrations with the DI container with types a source generator has generated).
I watched the super good Build Talk and scanned through some of the docs in csharplang. Based on the docs stating that extension types will be implemented as (ref) structs(?), makes me believe the way the compiler chooses the extension (type) method will slightly change with extension types/and will be more restrictive(?) than the current mechanism with extension methods. If that was the case and library authors adapted the new model, that could be a breaking change.
When generating the struct for extension types a) is something similar to the existing extension method call generated? Will it generate the call in the form [1] or [2] (spec indicates [1])? How does the compiler select the method? Will there be some mechanism to possible intercept such a call?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
With the current extension method mechanism (the old feature), there can (under certain circumstances) be multiple candidate extension methods. The compiler chooses the candidate extension method from the nearest namespace (forgive my utterly imprecise description).
This basically enables (for example, a source generator) to “intercept” (wrong term) and replace one extension method with another at build time. This is only possible if the extension method is called as an extension
[1]
obj.ExtensionMethod();
and not if it is called as a static method
[2]
MyExtensionClass.ExtensionMethod(obj);
Such a method can also not be intercepted by an interceptor (because it is static / correct me if this is also subject to change).
In the [1] case, a source generator could generate a new extension method in a namespace closer to the current namespace than the original extension method. This new method will then be selected by the compiler.
Disclaimer: I wouldn’t consider “replacing one extension method with another at compile time” a fabulous design choice. I am also a bit uncertain whether I like the rules how the compiler selects the extension method in the current version of the feature (understanding there is little to do it better). However, under certain circumstances, the option to replace/redirect an extension method or the ability to use an interceptor may be beneficial (scenario: modifying implementation types in registrations with the DI container with types a source generator has generated).
I watched the super good Build Talk and scanned through some of the docs in csharplang. Based on the docs stating that extension types will be implemented as (ref) structs(?), makes me believe the way the compiler chooses the extension (type) method will slightly change with extension types/and will be more restrictive(?) than the current mechanism with extension methods. If that was the case and library authors adapted the new model, that could be a breaking change.
When generating the struct for extension types a) is something similar to the existing extension method call generated? Will it generate the call in the form [1] or [2] (spec indicates [1])? How does the compiler select the method? Will there be some mechanism to possible intercept such a call?
Thanks for input.
Beta Was this translation helpful? Give feedback.
All reactions