il y aurait pu y avoir deux fonctions, une localisée et une sur laquelle on peut compter quel que soit le contexte. Je te l'accorde avec grand plaisir.
Par contre je ne suis pas d'accord sur le "aucune raison de dépendre d'une locale". Ton fichier dépend forcément d'une convention sur quoi mettre comme séparateur. Prendre comme convention de mettre le séparateur de ton pays n'est pas forcément plus crétin que prendre comme convention le séparateur d'un pays tierce.
> Alors effectivement, je serais d'accord avec ton point de vue si le
> fichier en question était en quelque sorte un fichier final, le but du
> traitement. Mais ça ne l'est pas, c'est juste un fichier de données
> sources que j'injecte dans le bouzin
Si je peux me permettre, ça ça n'a aucun sens. Parce que si le fichier est "source" pour toi, il est "final" pour quelqu'un d'autre, une application ou un humain.
Dire que la locale est pertinente en sortie mais pas en entrée c'est impliquer que les fichiers en entrée naissent par génération spontanée.
[^] # Re: coupable ?
Posté par Éric (site web personnel) . En réponse au journal Pourquoi je hais les locales. Évalué à 2.
Par contre je ne suis pas d'accord sur le "aucune raison de dépendre d'une locale". Ton fichier dépend forcément d'une convention sur quoi mettre comme séparateur. Prendre comme convention de mettre le séparateur de ton pays n'est pas forcément plus crétin que prendre comme convention le séparateur d'un pays tierce.
> Alors effectivement, je serais d'accord avec ton point de vue si le
> fichier en question était en quelque sorte un fichier final, le but du
> traitement. Mais ça ne l'est pas, c'est juste un fichier de données
> sources que j'injecte dans le bouzin
Si je peux me permettre, ça ça n'a aucun sens. Parce que si le fichier est "source" pour toi, il est "final" pour quelqu'un d'autre, une application ou un humain.
Dire que la locale est pertinente en sortie mais pas en entrée c'est impliquer que les fichiers en entrée naissent par génération spontanée.