Je viens de rencontrer quelque chose avec C # aujourd'hui que je n'avais pas pensé auparavant. J'ai deux méthodes dans ma classe, une surcharge de l'autre. Ils sont déclarés comme:
RequirePermissions(new string[] { "Permission1", "Permission2" });
RequirePermissions("Permission1", "Permission2");
5 Réponses :
Oui, j'accepte que cela devrait probablement être un avertissement lorsque vous utilisez des tableaux d'argumentation de longueur variable provoque une surcharge ambiguë - c'est très un cas de bord, et les gens ne veulent certainement pas créer de telles situations. P>
Je ne sais pas non plus de quelque manière que ce soit, autre que vous avez posté, pour éviter la résolution d'appel qui se produit - autre que d'éviter de le faire en premier lieu, ce que je recommanderais fortement! P>
Vous ne pouvez pas utiliser les paramètres et être explicite avec vos signatures.
public void RequirePermissions(string[] permissions)... public void RequirePermissions(string message, string[] permissions)..
Accepter avec Adam, je le changerais à quelque chose comme:
Putain, ne remarquez pas votre réponse avant après que je posais le mien. Les barres de défilement dans les échantillons de code font glacer mes yeux, je suppose.
Personnellement, je le ferais de cette façon:
public void RequireMessageAndPermissions(string message, params string[] permissions)...
public void RequirePermissions(params string[] permissions)...
On dirait qu'il n'y a pas d'autre moyen. P>
Vous pouvez trouver une explication à ce comportement en C # SPEC http: //www.jaggersoft .com / csharp_standard /17.5.1.4.htm et ici http: // www.jaggersoft.com/cshaarp_standard/14.4.2.1.htm (paragraphe 2) p>
Un tableau de paramètres est précisément équivalent à un paramètre de valeur (§17.5.1.1) du même type. P> blockQuote>
et p>
La forme expansée d'une méthode n'est disponible que si la forme normale de la méthode n'est pas applicable et seulement si une méthode avec la même signature que la forme expansée n'est pas déjà déclaré dans le même type p> blockQuote>
Regardez ici- ayende.com/blog/archive/2007 /12/31/tricky-code.aspx et ici- Yoda.Arachsys .com / csharp / teasers.html (n ° 6)
Je suis un peu confus par votre suggestion. Pensez-vous que l'avertissement devrait être sur le appel ambigu i> ou sur l'ensemble des déclarations i> qui pourraient conduire à un appel ambigu?