Tkfé

Je ne comprends pas pourquoi on ne fait pas simplement :

   internal static IEnumerable

<TResult> Select<TSource, TResult="">(this IEnumerable<TSource> source, Func<TSource, TResult=""> selector)

   {

       foreach (TSource s in source)

           yield return selector.Invoke(s);

   }

a mon avis la ligne rouge est inutile, non ?

Je suis d'accord, mais dans ta fonction Select, l'argument "source" est de type IEnumerable

<TSource>, tout comme "sourceEnum", donc la ligne rouge ne change rien. Dans les deux cas, c'est l'extension method de IEnumerable qui sera appellee.

Et avec ou sans cette ligne rouge, il est de toute façon impossible de re-caster le resultat en IQueryable puisque tu renvoie un resultat en utilisant yield return.

Tu as peut etre fait une faute de frappe et voulait mettre IQueryable<TSource> comme type pour l'argument "source".

Je corrige mon precedent commentaire: quel que soit le type de l'argument "source" (IQueryable ou IEnumerable), il n'y a pas besoin de le caster en IEnumerable pour lui appliquer un foreach (l'appel à GetEnumerator sera de toute façon le même).

Mais après reflexion, je suis quasiement sur que la ligne rouge ne sert à rien (c'est le foreach/yield return qui est important).

Bien entendu, Flavien a raison. En effet, un IQueryable est un IEnumerable donc cette ligne "IEnumerable

<TSource> sourceEnum = source;" ne sert à rien.

En revanche, je ne comprend pas du tout ton histoire de cast.

On pourrait recaster dans la couche présentation si on retournait directement la source.

Dans la mesure où on reparcourt l'énumération et où on en recrait une avec yield return, il n'est plus possible de recaster en IQueryable. Donc on ne peut pas rejouer avec LINQ To SQL dans ce cas.

Où alors il y a quelque chose qui m'a échappé.

"La grande question est pourquoi cette surcharge de la méthode Select de Linq To Objects, permet de modifier le comportement de notre couche d'accès".

On est bien d'accord que l'extension method, ça n'existe pas au sens IL. Donc le compilateur doit appelait la méthode static. Pour cela, quand il peut choisir enytre plusieurs extension methods, il choisit celle la plus typée et, dans le cas où il y en aurait deux avec le même typage, il ne pourra pas choisir à moins qu'une et une seule des deux soient définies dans la même assembly et le même namespace.

Je ne vois pas où est le problème.

Petite correction à mon commentaire précédent :

Le compilateur choisit d'abord l'extension method la plus typée dans l'assembly et dans le namespace d'appel avant de chercher les autres dans le cas où il n'en trouve pas. C'est pour ça que même si ta redéfinition du Select prend un IEnumerable en paramètre et qu'il aurait pu trouver dans System.linq.Queryable.Select une extension method plus typé (avec un IQueryable), c'est la tienne qui est appelée.

J'apporte encore une dernière correction. On s'en fout que ce soit dans la même assembly.

Le compilateur cherche la méthode la plus typée dans le namespace et s'il n'en trouve pas, cherche dans le reste.

Allez, juste une petite critique, je trouve le mot surcharge mal adapté. La règle de choix d'une méthode d'extension se fait sur la nature de la référence puis sur la visibilité courante des définitions de méthodes d'extension. Même si on peut jouer sur cette visibilité, ce n'est pas une surcharge, c'est un remplacement. J'entends là que par exemple si tu remplaces le 'Select' de IQueryable par le tiens, il ne sera jamais utilisé par le provider qui implémente IQueryable...

C'est comme si on avait une donnée membre 'int i' dans une classe et qu'on déclarait une variable 'int i' dans une méthode. Elle aurait alors une portée plus courte et remplacerait la résolution de la donnée membre du même nom. Pour autant, on n'appelle pas ça une surcharge.