Version imprimable
bonjour j'ai lu ca
Si plusieurs méthodes sont acceptables, le compilateur essaie d’en trouver une qui soit
meilleure que toutes les autres. Pour ce faire, il procède par éliminations successives. Plus
précisément, pour chaque paire de méthodes M et M’, il regarde si tous les arguments
(muets, cette fois) de M sont compatibles par affectation avec tous les arguments muets de
M’ ; si tel est le cas, M’ est éliminée (elle est manifestement moins bonne que M)
c'est quoi un argument muet
merci
Bonne question, merci de l'avoir posée....Citation:
Envoyé par yacin87
Sérieusement, tu le sort d'où ce texte ?8O
slt c'est dans le livre de claude delonney programmez en java
merci
Sur le peu que je lis, cela ressemble à un des problèmes de l'héritage multiple, même héritage qui n'existe pas en java. Es-tu sur que le contexte parlais de java et non d'une comparaison avec le C++ ?
Ca ressemble aussi à la résolution des méthodes surchargées.
si il parle d"'argument muet, un bon lovre t'as surement expliqué avant ce qu'est un argument muet, sinon, tu jette au feu :)
Un argument muet c'est :
C'est un argument formel qui ne peut être qu'un indicateur de variables. On trouve les arguments muets dans les déclarations de fonction(et non leurs appels dans le programme).
Code:
2
3
4
5
6
7
8
9
10
11
12
L'argument est dit muet car, au final, on peut lui retourner n'importe quelles valeurs sans que cela ai de l'importance.
Par contre ce que je ne comprend pas moi, c'est, qu'est ce qu'un argument non muet dans ce cas alors ? Puisque je ne connais, et est codé, que des fonctions à argument muet au final. Donc je ne vois pas trop pourquoi distinguer cette notion si je ne connais pas son contraire.
Bah ca peut toujours se revendre sur Priceminister mais avec peut être un sentiment d'arnaquer l'acheteur :mouarf:Citation:
si il parle d"'argument muet, un bon lovre t'as surement expliqué avant ce qu'est un argument muet, sinon, tu jette au feu
Après lecture des extraits du bouquin cité, il semble qu'il explique bel et bien de quoi il s'agit. Mais je suis pas sûr d'avoir compris.
Je pense qu'il s'agit simplement de distinguer deux choses quand on parle d'arguments :
- Est-ce qu'on parle des arguments que la méthode peut prendre, ceux auxquels on donne un nom dans la définition de la méthode, nom qui sera utilisé pour les identifier dans le corps d'implémentation de la méthode. Ceux-là, apparemment, seraient appelés les arguments muets.
- Ou est-ce qu'on parle des arguments qu'on passe au moment de l'appel de méthode, autrement dit, des expressions qu'on passe en argument de cet appel de méthode. Ceux-là seraient appelés les arguments effectifs
La distinction existe, en gros, il s'agit de dire si on est en train de regarder une déclaration de méthode ou un appel de méthode.
C'est effectivement important de savoir faire la différence quand on calcule la résolution de méthodes surchargées.
Drôles de noms, toutefois.
si c'est ça, personellement, j'au toujours entendu appeler ça respectivement: les arguments de la méthodes, et les valeur/paramètres effectives/ifs :lol:
La distinction me semblant d'ailleurs plus claire à faire dans ce cas, car je vois absolument pas ce que le mot "muet" viens faire là dedans, c'est pas comme si ça parlait en général un argument :aie: Bref un auteur qui s'est inventé son vocabulaire à lui?
C'est un vocabulaire utilisé en mathématiques. Une variable muette est une variable qui sera remplacée par des valeurs effectives lors de l'utilisation d'une fonction mathématique pour calculé la valeur de retour :
par exemple :
f(x) = x²
x est une variable muette.
C'est un peu plus compliqué que ça mais vous avez l'idée.
Cela fait partie de la notion mathématique "est fonction de ... ", c'est pour cela qu'on l'a retrouve en programmation :
On dit que :Code:
2
3
4
- L'image de x par la fonction "func" est y
- L'antécédent de y par la fonction "func" est x
Faisons une analogie :
Prenons l'exemple d'un appareil photo : L'image du paysage (ici x), par la fonction "appareil photo" (ici "func") est la photo (ici y)
Maintenant que j'ai mis au clair "est fonction de ...", parlons de cette fameuse variable timide ( :troll: )
Prenons un exemple : f(x) = x*t
Ici x est muette car le résultat ne dépend pas d'elle.
C'est plutôt compliquer a concevoir, mais le résultat dépend de t et non de x
Comprendo ? :aie:
Bien sûr que le résultat dépend de x -_-°.Citation:
Envoyé par TheZopo
Je ne sais pas vraiment quel est l'idée derrière l'adjectif muette, mais j'imagine que ça doit être ainsi :
x "ne dit rien".
x ne fait pas partie du problème que nous sommes en train d'étudier. x est une variable que nous avons arbitrairement créée pour le seul besoin de définir comment on calcule les images des valeurs par f. À tout moment du problème nous pourrions réécrire f(x) par f(y) et cela ne modifierait pas le problème.
Exemples de variables non-muettes :
- Soit a un réél quelconque. Nous allons étudier la fonction f(x) = a * x
x est muette, a ne l'est pas. La variable a est créée par l'énoncé du problème, et pas seulement pour le seul contexte de la définition de f.
- Soit f(x) = 2 * x + 8
On notera x0 le nombre réél tel que f(x0) = 0
x est muette, x0 ne l'est pas. Pour les mêmes raisons.
Oui, en fait c'est ce que je voulais dire, je me suis embrouillé tout seul en pensant aux irrationnels, enfin bref, je suis partis très loin là :arf:Citation:
x ne fait pas partie du problème que nous sommes en train d'étudier. x est une variable que nous avons arbitrairement créée pour le seul besoin de définir comment on calcule les images des valeurs par f. À tout moment du problème nous pourrions réécrire f(x) par f(y) et cela ne modifierait pas le problème.
Moi j'aurais dit que x est une variable muette car la fonction f comme un tout, c'est-à-dire la courbe de f, ou le mécanisme qui fait le calcul de l'image d'un antécédent par f, ne dépend pas de x.
Par contre dans une fonction du genre " f(x) = a*x " la courbe de f dépend de a.
Pour ce qui est du mot "muette", c'est probablement parce que x n'ajoute aucune information sur la nature de la fonction f. Par contre "a" dans l'exemple précédent ajoute une information sur la courbe de f (qui est la pente dans ce cas).
Je trouve tout ce vocabulaire particulièrement "savant" pour des choses bien plus simple...
Ha bah oui, mais les maths "abstraites" c'est toujours compliqué...
@Sami : Je pense que c'est ça, moi aussi
Pas si simple que ça, comme on s'en rend compte quand on discute conception de compilateur avec des programmeurs pas habitués.Citation:
Envoyé par kolodz
Bonjour à tous,
La question se trouve à la page 137 (164 sur 816) du livre cité, Chapitre 8, "Surdefinition des méthodes".
Quant à l'info sur l'argument muet, elle est disponible à partir de la page 126 (153 sur 816), Chapitre 6 "Les classes et les objets" du livre même livre (Edition Eyrolles 2008):
Si besoin: je reste à la disposition des utilisateurs avisés pour plus de renseignements.Citation:
6.2 Les arguments d’une méthode
6.2.1 Arguments muets ou effectifs
Comme dans tous les langages, les arguments figurant dans l’en-tête de la définition d’une
méthode se nomment arguments muets (ou encore arguments ou paramètres formels). Ils
jouent un rôle voisin de celui d’une variable locale à la méthode, avec cette seule différence
que leur valeur sera fournie à la méthode au moment de son appel. Par essence, ces arguments
sont de simples identificateurs ; il serait absurde de vouloir en faire des expressions.
Il est possible de déclarer un argument muet avec l’attribut final. Dans ce cas, le compilateur
s’assure que sa valeur n’est pas modifiée par la méthode :
Les arguments fournis lors de l’appel de la méthode portent quant à eux le nom d’argumentsCode:
2
3
4
5
6
7
8
effectifs (ou encore paramètres effectifs). Comme on l’a déjà vu à travers de nombreux exemples,
en Java, il peut s’agir d’expressions (bien sûr, un simple nom de variable ou une constante
constituent des cas particuliers d’expressions). On notera que cela n’est possible que
parce que ce sont les valeurs de ces arguments qui seront effectivement transmises1 ; nous
reviendrons en détail sur ce point au paragraphe 9.
Bonne soirée à tous!
Hummm, mais ici c'est normal qu'il y est une erreur sur n = 12 car on a le mot clef "final" devant sa déclaration...
Oui... C'est effectivement ce que dit le texte autour -_-°Citation:
Envoyé par TheZopo
:pastaper:
L’ambigüité viens d’un certain livre informatique en français qui emploi ce terme paramètre muet hors contexte notamment avec le mot clé final de java.
En Java, le mot-clé "final" est utilisé pour déclarer une variable, une méthode ou une classe comme immuable, ce qui signifie que sa valeur ou son comportement ne peut pas être modifier une fois initialiser mais elles sont tout à fait utilisables.
Ça veut dire que si une fonction a comme paramètre un primitif ou un objet déclarer final ou non celui-ci ne peut être dit muet sauf si dans le corps de cette fonction il n'est pas du tout utilisé.
En programmation, le terme "paramètre muet" est généralement utilisé pour désigner des paramètres définis dans une signature de fonction mais qui ne sont pas utilisés dans le corps de la fonction.
En anglais, le terme "muet" pour décrire des paramètres inutilisés ou sans effet est généralement traduit par "unused parameter" ou "dummy parameter". D'autres termes peuvent également être utilisés en fonction du contexte, tels que "redundant parameter", "superfluous parameter", ou "ignored parameter".
Voici quelques exemples de situations où le « terme muet » peut être utilisé pour décrire des paramètres qui ne sont pas utilisés ou qui n'ont pas d'effet sur le comportement d'une fonction ou d'une méthode :
Dans une interface de programmation, il peut y avoir des méthodes ou des fonctions qui prennent des paramètres dont la valeur n'est pas utilisée à l'intérieur de la méthode ou de la fonction. Dans ce cas, on peut dire que ces paramètres sont "muet", car leur valeur n'a aucun effet sur le comportement de la méthode ou de la fonction.
Dans certaines situations, il peut arriver qu'une fonction doive prendre un certain nombre de paramètres pour respecter une convention ou une interface de programmation, mais que certains de ces paramètres ne soient pas nécessaires pour la logique interne de la fonction. Dans ce cas, ces paramètres peuvent être considérés comme "muet", car leur valeur n'a aucun effet sur le comportement de la fonction.
Dans le cadre de la programmation parallèle, il peut arriver qu'une fonction doive prendre un certain nombre de paramètres pour être exécutée sur plusieurs threads ou processus, mais que certains de ces paramètres ne soient pas utilisés dans tous les threads ou processus. Dans ce cas, ces paramètres peuvent être considérés comme "muet" dans les threads ou processus où ils ne sont pas utilisés.
Il est important de souligner que dans tous ces cas, les paramètres "muet" peuvent être utiles pour des raisons de compatibilité ou d'interface de programmation, même s'ils n'ont pas d'effet sur le comportement de la fonction ou de la méthode. Cependant, il est également important de veiller à ne pas surcharger inutilement les interfaces de programmation avec des paramètres qui ne sont pas nécessaires.