Maintenant si ton besoin, c'est de pouvoir éditer un commentaire après coup suite aux réponses des autres participants, ben dis-le de suite, plutôt que de te cacher derrière une raison fallacieuse. Parce que là je ne suis pas d'accord avec toi. Quand tu dis des mots avec ta bouche, une fois que les mots sont dits, ils sont dits. Si il y a malentendu, tu t'expliques, tu ne peux pas "enlever" les mots qui ont été dits. La sur linuxfr, c'est pareil. A toi d'assumer tes propos et de les expliquer si besoin, ou de t'excuser si tu blesses quelqu'un.
Je ne comprends pas ce que tu insinues. Mon envie c'est de corriger mes posts pour que les gens qui ne les ont pas encore lu aient une expérience de lecture plus agréable, sans casser la cohérence de la discussion.
Si quelqu'un en dessous poste pour me faire remarquer une faute d'orthographe, ou même que j'ai fait un contresens par rapport à ce que je voulais dire (oublié un "ne pas", c'est l'exemple donné par baud123), j'édite mon message pour corriger le corps du commentaire, et je rajoute en bas une petite note "Edit: corrigé suite à la remarque de 'truc'", pour que les gens ne soient pas étonnés en lisant son commentaire (quoi il critique une faute qui n'existe pas) ou n'aient pas à aller regarder l'historique de mon message pour comprendre sa remarque.
Si j'utilise une formulation blessante dans mon premier jet et que je juge finalement inutile, je peux aussi la retirer (pas la peine de mettre de l'huile sur le feu) tout en annonçant que j'ai corrigé mon message pour enlever l'attaque inutile. En présence d'un historique, ça ne veut pas dire que je n'assume pas, la personne visée a tout à fait le droit de poster le lien vers l'ancienne révision de mon message pour montrer que, à chaud, je me suis comporté comme un rustre.
1/ Qu'n sais-tu ?
Cf. mon calcul ci-dessous.
2/ On voit bien que ce n'est pas toi qui aura à gérer les conséquences
On voit bien ce que n'est pas toi qui a à implémenter les limitations proposées.
3/ Si tu ne mets pas de limite, tu trouveras toujours quelqu'un qui abusera et détournera le système.
Comme je l'ai démontré dans mon calcul, un abus humain ponctuel (je ne parle pas d'un bot automatique qu'il faut de toute façon interdire à plus haut niveau au lieu d'implémenter des bridages incohérents sur chaque fonctionnalité du site; d'ailleurs aujourd'hui un tel bot pourrait déjà plomber la mémoire du serveur en éditant le wiki à répétition, l'ajout de la fonctionnalité de brouillons n'ajoute aucun risque supplémentaire) ne peut pas surcharger le site. Encore une fois, pourquoi s'embêter à optimiser sur un critère qui ne sera jamais un problème en pratique ? C'est de l'optimisation prématurée.
On s'en fout, c'est comme ça qu'on se retrouve avec des applis Java qui assent 90% a traverser des couches et des surcouches pour aller récupérer et afficher une info située dans une table de BDD.
Si l'appli Java n'est utilisée que très rarement, et que le temps total perdu en couche traversées est largement inférieur au temps dont aurait eu besoin le développeur pour réorganiser son application, ou à d'autres temps de calcul déjà présents dans l'application, il a certainement fait le bon choix.
[^] # Re: ouha-ou
Posté par gasche . En réponse au journal L'édition des commentaires sur LinuxFR, ou pas ?. Évalué à -1.
Je ne comprends pas ce que tu insinues. Mon envie c'est de corriger mes posts pour que les gens qui ne les ont pas encore lu aient une expérience de lecture plus agréable, sans casser la cohérence de la discussion.
Si quelqu'un en dessous poste pour me faire remarquer une faute d'orthographe, ou même que j'ai fait un contresens par rapport à ce que je voulais dire (oublié un "ne pas", c'est l'exemple donné par baud123), j'édite mon message pour corriger le corps du commentaire, et je rajoute en bas une petite note "Edit: corrigé suite à la remarque de 'truc'", pour que les gens ne soient pas étonnés en lisant son commentaire (quoi il critique une faute qui n'existe pas) ou n'aient pas à aller regarder l'historique de mon message pour comprendre sa remarque.
Si j'utilise une formulation blessante dans mon premier jet et que je juge finalement inutile, je peux aussi la retirer (pas la peine de mettre de l'huile sur le feu) tout en annonçant que j'ai corrigé mon message pour enlever l'attaque inutile. En présence d'un historique, ça ne veut pas dire que je n'assume pas, la personne visée a tout à fait le droit de poster le lien vers l'ancienne révision de mon message pour montrer que, à chaud, je me suis comporté comme un rustre.
Cf. mon calcul ci-dessous.
On voit bien ce que n'est pas toi qui a à implémenter les limitations proposées.
Comme je l'ai démontré dans mon calcul, un abus humain ponctuel (je ne parle pas d'un bot automatique qu'il faut de toute façon interdire à plus haut niveau au lieu d'implémenter des bridages incohérents sur chaque fonctionnalité du site; d'ailleurs aujourd'hui un tel bot pourrait déjà plomber la mémoire du serveur en éditant le wiki à répétition, l'ajout de la fonctionnalité de brouillons n'ajoute aucun risque supplémentaire) ne peut pas surcharger le site. Encore une fois, pourquoi s'embêter à optimiser sur un critère qui ne sera jamais un problème en pratique ? C'est de l'optimisation prématurée.
Si l'appli Java n'est utilisée que très rarement, et que le temps total perdu en couche traversées est largement inférieur au temps dont aurait eu besoin le développeur pour réorganiser son application, ou à d'autres temps de calcul déjà présents dans l'application, il a certainement fait le bon choix.