Discussion :

[Iradrille]

Ce qui est toujours le cas - si ça ne l'était pas, alors ça voudrait dire qu'on crée des instances d'objets invalides, ce qui n'est pas nécessairement une bonne chose A la construction, un membre est nécessairement valide, sans quoi on aura d'autres problèmes qui ne sont plus vraiment de mon ressort

C'est vrai la plupart du temps. Pour des questions d'optimisation il est possible de construire des objets "invalide" (valide mais contenant des valeurs invalides) comme par exemple un tableau (ou vector, ici n'est pas la question) d'enum, pas de valeur par défaut -> données invalides.

(edit: ça fait plusieurs fois que je me pose cette question (bien que très HS), mais est-il possible d'afficher le dernier message posté en début de nouvelle page ?)

[white_tentacle]

C'est vrai la plupart du temps. Pour des questions d'optimisation il est possible de construire des objets "invalide" (valide mais contenant des valeurs invalides) comme par exemple un tableau (ou vector, ici n'est pas la question) d'enum, pas de valeur par défaut -> données invalides.

Yep, mais dans ce cas, il est préférable de séparerer la notion d’allocation de celle de construction. Ton objet est invalide car seulement alloué mais pas encore construit.

Un exemple avec vector puisque tu en parles : reserve va faire l’allocation mémoire, mais sans plus. L’objet reste valide, même si toute une partie de la mémoire allouée est invalide.

[oodini]

En revanche, il va parler des arguments du verbe (COD / COI en français, quoi que ça a changé de nom depuis je crois, en anglais je ne connais pas les termes équivalents). Et je ne vois comment on peut honnêtement comprendre ça autrement que par les arguments de la fonction.

Il va surtout parler de la préposition to, que dans ta grande honnêteté, tu oublies de mentionner.
Pour avoir le sens que tu sembles donner à une fonction set(), il faudrait l'appeler setTo() ou setAt(). Sinon, il ne reste que les parenthèses, qui signifient en fonction de, et rien de plus. Je ne vois pas de quel droit on rajouterait une couche sémantique.

Je renvoie vers le dictionnaire d'Oxford, qui était cité. Tu verras que la mention adverb/preposition est citée maintes fois.

Essaye donc de faire une vraie phrase en anglais avec le verbe set et une valeur. Tu seras obligé de préciser ta pensée concernant l'utilisation de la valeur.

[oodini]

Yep, mais dans ce cas, il est préférable de séparerer la notion d’allocation de celle de construction. Ton objet est invalide car seulement alloué mais pas encore construit.

L'objet peut-être valide, mais pas tous les services qu'il offre.

L'objet peut lui même se rendre valide, longtemps après avoir été construit, par une évaluation paresseuse. On n'est donc jamais confronté à son invalidité.

[Iradrille]

Essaye donc de faire une vraie phrase en anglais avec le verbe set et une valeur. Tu seras obligé de préciser ta pensée concernant l'utilisation de la valeur.

obj.computerPleaseSetTheLenghtWhichIsInMeterTo(12);
vs
obj.setLenght(12);

Préciser sa pensé en faisant des phrases complètes ne rend pas forcément le code plus lisible, et il n'y a que peu d’intérêt à rajouter une préposition aux verbes, exemple :
"setLenghtTo" n'apporte rien par rapport à "setLenght".
La préposition est sous entendue et le but de la fonction est compris de tout le monde (si ce n'est pas le cas, alors oui rajouter une préposition, ou renommer la fonction peut aider à la compréhension)

[oodini]

obj.computerPleaseSetTheLenghtWhichIsInMeterTo(12);
vs
obj.setLenght(12);

Préciser sa pensé en faisant des phrases complètes ne rend pas forcément le code plus lisible

L'argumentation par excès ne peut que décrédibiliser son auteur. Je n'ai jamais parlé de faire des phrases, mais seulement de donner le verbe dans sa totalité (préposition comprise, donc).

et il n'y a que peu d’intérêt à rajouter une préposition aux verbes

Énorme erreur, particulièrement en anglais où les préposition ont une importance capitale. Je t'invite à aller consulter dans un dictionnaire toutes les déclinaisons du verbe get.

"setLenghtTo" n'apporte rien par rapport à "setLenght".

Si. Le premier que la valeur du membre doit être égale à l'argument, et le second que la valeur du membre est fonction de l'argument.

La préposition est sous entendue

On pourrait tout autant sous entendre set from.

et le but de la fonction est compris de tout le monde

Uniquement pour des raisons d'usage.

[Iradrille]

L'argumentation par excès ne peut que décrédibiliser son auteur. Je n'ai jamais parlé de faire des phrases, mais seulement de donner le verbe dans sa totalité (préposition comprise, donc).

Essaye donc de faire une vraie phrase en anglais avec le verbe set et une valeur. Tu seras obligé de préciser ta pensée concernant l'utilisation de la valeur.

rhoo.

Uniquement pour des raisons d'usage.

C'est toujours une raison d'usage. Sans vouloir te mettre au défi, je pense que tu ne peux pas trouver une utilisation de "get" avec préposition dans une librairie.
C'est juste une "habitude", tout comme c'est une "habitude" de nommer les fonctions/variables en anglais, pour l'instant on peut pas changer ça, d'ici quelques dizaines d'années pourquoi pas, je serai curieux de voir ça =).

[oodini]

C'est toujours une raison d'usage. Sans vouloir te mettre au défi, je pense que tu ne peux pas trouver une utilisation de "get" avec préposition dans une librairie.

Ben pour le get, en l'occurrence, il n'y a pas d'argument, et donc pas d'ambigüité.

D'autant plus que le sens sans préposition est le sens d'usage.

Défi relevé.

[white_tentacle]

Si. Le premier que la valeur du membre doit être égale à l'argument, et le second que la valeur du membre est fonction de l'argument.

Interprétation strictement personnelle de la langue anglaise.

Pour le reste, j’arrête la discussion ici : elle est complètement bloquée et n’arrivera nulle part. Je t’invite quand même à la relire entièrement, à tête reposée, et espère que tu reverras tes positions.

C'est toujours une raison d'usage. Sans vouloir te mettre au défi, je pense que tu ne peux pas trouver une utilisation de "get" avec préposition dans une librairie.

getAt se trouve assez facilement.

Mais il ne faut pas confondre un COI avec un phrasal verbs (verbe prépositionnel), ce que vous êtes en train de faire allègrement (la préposition modifie le sens du verbe SI c’est un phrasal verb, pas si c’est la préposition du coi. Si vous trouvez ça tordu, plaignez vous aux anglais, pas à moi ).

get into bed : phrasal verb (get into) + COD
set length to ten : verb + COD + COI (set to en tant que phrasal verb existe, mais n’a pas du tout le même sens)

[Emmanuel Deloget]

Ca ressemble à une discussion de coupeur de cheveux en 4

Non. Cela voudrait dire qu'on crée des objets valides dotés de champs à valeur logiquement invalides.
Exemple : utilisation de NotANumber.

Je crois que j'ai déjà dit ça quelque part : une valeur existe toujours, et peut être invalide. Une entité est toujours valide quand elle existe, mais elle peut ne pas exister.

Si ta valeur invalide est partie d'un objet à sémantique de valeur, alors ton objet est alors invalide dans son ensemble (seul cas contraire : ton objet valeur n'est pas assez précis et englobe trop de chose ; je pars du raisonnement suivant : si un objet est valide et contient une valeur qui ne l'est pas, alors cette valeur n'est pas nécessairement corrélée aux autres valeurs qui composent l'objet. Le fait qu'elle soit corrélée "de temps en temps" n'est pas une motivation suffisante pour l'inclure dans l'objet ; bref, c'est un problème de conception).

Si tu utilises une valeur invalide dans un objet à sémantique d'entité, alors cette entité est dans de beaux draps

Si on veut communiquer son intention uniquement par le nom de la fonction, il faut justement bien choisir ce nom, avec le verbe adéquat.

C'est justement mon propos : set, même s'il est très couramment utilisé (idiomatique pourrait-on dire), n'est quasiment jamais un verbe adéquat. S'il parait l'être, je soupçonne que ça cache en fait un problème d'architecture (c'est la sensation que j'ai, et je n'arrive pas à la formaliser correctement).

En l'occurrence, la vitesse étant affectée à un tronçon de route, on ne fait pas en sorte que la route accélère...

Et pourquoi pas ?

Ah, ok, je vois

Plus sérieusement, on va effectivement éviter d'accélérer la route - certains pourraient se servir de ce prétexte pour justifier des accidents qui sont en grande partie du à leur taux d'alcoolémie

Sauf que tu ne disposes pas toujours de la valeur au moment de la construction de l'objet.
Je veux construire mes millions d'objets quand je lance mon application, pas en prod quand je reçois de quoi setter les valeurs.

Je le comprends bien. Ceci dit, tu ne peux pas prétendre construire une valeur si tu ne la met pas au moins dans un état connu - que cet état connu soit un état valide ou non. Encore une fois, je ne critique pas le fait d'initialiser une valeur spécifique - mais je critique l'utilisation de set. En cherchant, on trouvera toujours des cas où, à priori, set est un nom tout à fait adapté. Mon propos est que dans l'immense majorité des cas, on peut trouver un vocable plus adapté. Et mon propos sous-jacent est que, même si je pense être à peu près correct sur ce point, cette pensée n'engage que moi - autrement dit, je peux me tromper (ça ne sera pas la première ni la dernière fois).

Et l'évaluation paresseuse, vous en faite quoi ?

Rien. Si l'évaluation paresseuse a pour but de construire un objet à sa première utilisation, alors elle est virtuellement indistinguable d'une construction complète au préalable. Au niveau du comportement du programme, ça ne change rien (au niveau de l'utilisation des ressources par contre, il y a des différences notables). C'est une optimisation - et comme toutes les optimisations, elle n'est pas censée changer le comportement global du programme, même si elle peut avoir un effet très local.