Effectivement, il y a peu de chances pour que ça arrive mais ça coûte rien d'y penser : je ne sais pas sur quel simulateur ce script tournera.
Si un changement soudain de temporalité survient (par exemple si l'utilisateur change la date sur le système sous-jacent), je ne vois pas bien ce que ça change : s'il va dans le futur brusquement, il obtiendra probablement rien car le script se ré-initialise après 5 secondes d'inactivité ; s'il va dans le passé subitement, il obtiendra un bpm négatif et ça correspondra bien à la réalité perçue du point de vue du script : il fait ce qu'on lui a demandé même si c'est le Docteur Who qui appuie sur la touche entrée.
Le seul problème réel est dans le cas d'une durée nulle : une durée nulle ça n'existe pas, c'est seulement une absence de durée : ça n'aurait pas les propriétés qu'on peut légitimement attendre d'une durée.
Bonjour et merci à toi car ta démarche m'a inspiré, je trouve que ce que tu as fait avec Taptempo est très chouette.
Les exits servent à éviter que mon script plante comme un gros tas au cas où l'utilisateur lui demanderait de faire des choses déraisonnables, comme par exemple demander un nombre négatif de chiffres après la virgule ou bien calculer une durée à partir d'un seul échantillon : dans un premier je type fortement les données que l'utilisateur essaye de transmettre au programme, ensuite je lis le cahier des charges et je réduis la voilure au maximum.
De manière générale, je ne programme jamais mais quand je le fais, je fais tout pour que le programme refuse de fonctionner le plus souvent possible. C'est pour la même raison que je teste si du temps s'est écoulé entre deux dates avant de faire une division par la durée entre ces deux dates, ça évite de faire un division par zéro et ça donne la bonne réponse à la place.
[^] # Re: L'infini
Posté par Glaeken (site web personnel) . En réponse au journal Portage de TapTempo en Perl6. Évalué à 4.
Effectivement, il y a peu de chances pour que ça arrive mais ça coûte rien d'y penser : je ne sais pas sur quel simulateur ce script tournera.
Si un changement soudain de temporalité survient (par exemple si l'utilisateur change la date sur le système sous-jacent), je ne vois pas bien ce que ça change : s'il va dans le futur brusquement, il obtiendra probablement rien car le script se ré-initialise après 5 secondes d'inactivité ; s'il va dans le passé subitement, il obtiendra un bpm négatif et ça correspondra bien à la réalité perçue du point de vue du script : il fait ce qu'on lui a demandé même si c'est le Docteur Who qui appuie sur la touche entrée.
Le seul problème réel est dans le cas d'une durée nulle : une durée nulle ça n'existe pas, c'est seulement une absence de durée : ça n'aurait pas les propriétés qu'on peut légitimement attendre d'une durée.
[^] # Re: L'infini
Posté par Glaeken (site web personnel) . En réponse au journal Portage de TapTempo en Perl6. Évalué à 3.
Bonjour et merci à toi car ta démarche m'a inspiré, je trouve que ce que tu as fait avec Taptempo est très chouette.
Les exits servent à éviter que mon script plante comme un gros tas au cas où l'utilisateur lui demanderait de faire des choses déraisonnables, comme par exemple demander un nombre négatif de chiffres après la virgule ou bien calculer une durée à partir d'un seul échantillon : dans un premier je type fortement les données que l'utilisateur essaye de transmettre au programme, ensuite je lis le cahier des charges et je réduis la voilure au maximum.
De manière générale, je ne programme jamais mais quand je le fais, je fais tout pour que le programme refuse de fonctionner le plus souvent possible. C'est pour la même raison que je teste si du temps s'est écoulé entre deux dates avant de faire une division par la durée entre ces deux dates, ça évite de faire un division par zéro et ça donne la bonne réponse à la place.