(Remarque: la motivation pour cela nécessite une explication longue et difficile; vous pouvez trouver la discussion complète sur ce problème d'accord . Ce n'est peut-être même pas la bonne solution au problème, mais je pense que la question est intéressante en soi.) Je cherche un moyen de mettre en œuvre un opérateur binaire tel que le comportement dépend du type de l'opérande à droite: un comportement s'il est identique à l'opérande de gauche, de comportement différent, sinon . Comme exemple: La première surcharge est plus spécifique que la seconde, vous pouvez donc vous attendre à une invocation telle que J'ai réussi à contourner cela de manière à ajouter d'ajouter un paramètre de type à la première surcharge , mais c'est exactement ce que j'essaie d'éviter. Une solution différente serait de modifier la surcharge générique pour exiger des preuves du compilateur qu'il n'y a pas de sous-typing relation entre les types (l'opposé de S'il est généralement assez facile d'encoder des relations de sous-typing dans Scala, je n'ai trouvé aucun moyen de coder le manquant de celui-ci. Y a-t-il un moyen d'exiger que, pour que la deuxième surcharge soit candidate à la compilation, ni 5 testtagainst 10 pour déclencher le Première surcharge, alors que 5 TestAgainSt "ABCD" invoquerait la deuxième surcharge. Bien que cela soit logique en théorie, cela ne compilera pas car la signature effacée est la même pour les deux surcharges. =: = , qui n'est malheureusement pas fourni par la bibliothèque Scala). < / P> t ou t>:> u est vrai? < / p>
3 Réponses :
Si vous souhaitez appliquer que deux types sont différents strictement à la compilation, alors C'est la question a > Pour vous. En utilisant l'une des réponses qui définit Nous pouvons également faire le test de type dans Une méthode utilisant Vous pouvez alors le modifier bien sûr pour brancher le comportement. P> =! = Code>, nous pouvons imaginer plusieurs méthodes qui ressemblent à ceci:
Typetag code> assez facilement. p> scala> 1 testAgainst 2
res98: Boolean = true
scala> 1 testAgainst "a"
res99: Boolean = false
scala> List(1, 2, 3) testAgainst List(true, false)
res100: Boolean = false
scala> List(1, 2) testAgainst List.empty[Int]
res102: Boolean = true
Merci! J'ai cherché mais j'ai évidemment manqué la question que vous avez référencée. Malheureusement, mon problème est un peu plus velu que la simple résolution implicite, mais la seule astuce implicite ambiguë valait seulement le prix de l'admission :-)
De plus, tant que vous n'avez pas besoin de soutenir des opérandes de droite génériques, il y a une solution réalisable ici: GITUB.COM/WIX/accord/issues/37#issuecomment-101213060 Malheureusement, dans mon cas, c'est exactement ce que je dois faire. La solution de réflexion d'exécution ne vous aidera évidemment pas à ...
@Tomergabel Retrait apparemment le premier implicite fait le tour.
La solution est en fait assez simple. Votre seul problème réel est que vos deux surcharges ont la même effacement, ce qui ne pose qu'un problème pour le compilateur en raison des limites de la JVM sous-jacente. En ce qui concerne la frappe, avoir ces deux surcharges conviennent parfaitement.
Donc, tout ce que vous avez à faire est de modifier la signature d'une surcharge de manière à ce qui est fonctionnellement équivalente. Cela peut être fait à l'aide d'un paramètre implicite qui sera toujours trouvé (typiquement, ou: DigoryImplicite ) ou en ajoutant un paramètre factice avec une valeur par défaut. Donc, l'une de celles-ci est bien (j'utilise habituellement la première version):
Bien que utile, cela ne répond pas à la question initiale (comment implémenter =! =). Je ne savais pas que je ne connaissais pas le matrice, cependant, alors merci!
Eh bien, je pensais que la question actuelle était de savoir comment "mettre en œuvre un opérateur binaire tel que le comportement dépend du type de l'opérande de droite: un comportement s'il est identique à l'opérande de gauche, de comportement différent, sinon", qui Comme votre exemple montre peut être fait à travers une surcharge simple (une fois "fixe", c'est-à-dire que je montre ci-dessus). De votre description apparaît que la recherche d'un =! = ne provient que de votre tentative de trouver une alternative à la surcharge car vous ne pouviez pas le faire fonctionner. Mais il peut travail, comme je l'ai montré. Qu'est-ce que j'ai raté?
Cette question particulière découle d'essayer de travailler autour d'une question plus importante dans une DSL basée sur SCALA; Ce que vous avez cité est essentiellement le contexte à la question plus précise. Rele lecture ma question, cependant, il semble que c'était un peu ambigu de ce que je cherche exactement, alors vous obtenez votre uppote de toute façon :-)
Comme un côté, ajoutant évidemment des pauses de surcharge paramétralisées de type ce que j'espérais réaliser en premier lieu (voir le bogue d'accord lié à la question), donc à ce stade, je suis sûr que le problème plus large ne peut pas vraiment être travaillé autour.
Il existe également un moyen de déterminer à l'exécution qu'il n'y a pas de relation de sous-typing entre les types basés sur des règles de résolution implicites et des valeurs implicites par défaut. Il peut être illustré par cette fonction simple et ses invocations: si type Ceci, cependant, ne fonctionnerais que lors de l'exécution, il ne répondrait probablement pas à votre question exactement, mais néanmoins, cette astuce peut parfois être utile. t n'est pas un sous-type d'un autre type u u , Le compilateur ne sera pas en mesure de trouver une valeur implicite pour t <: , et ainsi la valeur par défaut sera utilisée, ce qui est null dans ce cas. < / p>
Tant que vous testez le sous-typing strict, nécessitant des preuves que T <: :> u).
Eh bien, avec (implicite EV1: t <: si les deux arguments sont null au moment de l'exécution, les types sont alors pas de lien.
Oh wow, c'est une astuce soignée! Dommage que vous puissiez seulement l'évaluer au moment de l'exécution. Cela peut probablement être travaillé avec une macro, mais comme il y a un piratage différent qui fonctionne à la compilée (voir Stackoverflow.com/Questtions/6909053/force-Type-Différence comme liée par MZ) Cela ressemble à une overkill.
@Tomergabel, drôle, c'est que je n'ai examiné que cette réponse maintenant et il semble que cette astuce puisse être adaptée à travailler avec le sous-typant, il utilise la même approche de valeur par défaut null comme celui-ci.
Il y a plusieurs options; Mon préféré jusqu'à présent exploite des implicites ambiguës. N'aurait jamais pensé à cela dans un million d'années :-)