Discussion :

[RunCodePhp]

selon d'autres recherches que j'ai faite hier, je suis arrivé a une conclusion pas mal, t'en as partiellement parlé, je suppose donc qu'elle est pas mal, mais je suis sur que tu me sortiras des contres exemples...

Ce que tu as vu a tout l'air d'être le système de jeton que j'ai évoqué plusieurs, qui à mon sens à l'air d'être un moyen supplémentaire de sécuriser la session.

J'ai trouvé ceci : Sécurisation stateless PHP avec jeton (token) - protection CSRF en PHP
Il y a un code d'exemple.

Fais des recherche sur des comme "php jetons sessions" (ou tokens), dans ce genre là, tu aura pas mal d'infos.

parlant de CONSTANTE, penses tu que c'est mieux de mettre en constante le taux de change pour calculer par la suite la conversion de devise en PHP ou plutot tout faire en SQL lors de l'affichage des prix?

Alors là, franchement j'en sais rien.
Les "taux de change" ne changent ils pas tous les jours ? Ca doit être le cas, même si les écarts sont faibles.
Que dit la loi sur ce point ? Exige t-elle quelle soit quotidiennement actualisée où il y a des délais ?

Mais comme ça, n'oublie pas une autre astuce que j'avais évoqué qui est de générer automatiquement via l'espace Admin (que tu dois avoir) des fichiers, comme celles des devises par exemple.

Admettons que le taux est réactualisé en Bdd toutes les semaines coté Admin, et bien après le update on re-crée les euro.php, livre.php, etc ... donc les constantes.
La partie publique elle se réfère toujours aux constantes (fichiers inclus).
On peu éventuellement prévoir une alternative :
Si le fichier n'existe pas -> requête SQL Bdd et créer les constantes.
Le code plus loin ne bouge pas, il exploite toujours les mêmes constantes.

C'est ni plus ni moins le même principe que des systèmes de cache HTML basés sur des dates de validités.
Si le fichier n'existe pas ou la date est périmée (inférieur à 24 heures ou une semaine, peu importe) on recrée le fichier, et on l'inclus.

Cependant, faut quand même voir du coté hébergement,faut voir les limite à ce niveau là, comme le nombre de requêtes SQL.
Si ton offre/formule te donne de la marge par exemple par rapport à tes estimations (trafique), faire du SQL me semble bien plus simple, et tout aussi rapide sinon plus.
De même que se dire de payer un supplément, autre formule avec moins de limite pour éviter des sur-couches de codes, se simplifier la vie en résumé, me semble un argument tout à fait valable.
Faut voir.

erreur de ma part, j'utilise des require_once et non pas include_once

Peu importe, c'est du *_once surtout dont je faisais allusion.
Le *_once sous entend que c'est Php qui gèrera le cas, en cas d'erreur.
Si un bug a lieu, donc inclure un 2ème fichier par erreur, Php ne l'inclura pas, mais surtout ne génèrera pas d'erreur.
Ce bug peu très bien avoir lieu tout le temps, sur toutes les pages sans pour autant que quiconque s'en aperçoive.
C'est vicelard comme comportement, donc faut pas te laisser pièger par ce genre de détail.
C'est la même chose que les @ devant une fonction par exemple. C'est loin d'être une bonne façon de procéder.
Un simple require() tout court est théoriquement mieux dans ce cas là, car cette fois ça génèrera une erreur, donc on sera au courant du bug, donc on pourra le réparer.
Ca ne veut pas dire que les include_once ou require_once ne sont pas utiles, mais par moment ça ne s'y prête pas.

En gros, c'est comme si on débranchait tous les témoins lumineux d'avertissement du tableau de bord d'une voiture, comme celui de la température du moteur.
C'est sûr, on sera jamais embêter, même si la température monte de trop.
Enfin, jusqu'à que le moteur claque.

[redah75]

Ce que tu as vu a tout l'air d'être le système de jeton que j'ai évoqué plusieurs, qui à mon sens à l'air d'être un moyen supplémentaire de sécuriser la session

Oui, je vais donc aller pour cette solution. et merci pour le lien

Alors là, franchement j'en sais rien.
Les "taux de change" ne changent ils pas tous les jours ? Ca doit être le cas, même si les écarts sont faibles.
Que dit la loi sur ce point ? Exige t-elle quelle soit quotidiennement actualisée où il y a des délais ?

j'ai manqué de precision
j'aurai une tache cron qui se connectera tous les jour a une heure X pour recuperer les taux et mettra la table des devises a jour. sachant que la livre sera la devise principale.
pour l'instant, je ne sais encore trop comment va se derouler cette gestion de devise puisque je dois voir comment ca se passe avec la banque en angleterre:
si la banque me taxe en cas de paiement en Euro ou dollars, je dirais alors sur le site que la conversion en EUR ou USD est a titre indicatif et qu'ils seront debité du montant en LIVRE... on verra bien

Cependant, faut quand même voir du coté hébergement,faut voir les limite à ce niveau là, comme le nombre de requêtes SQL.
Si ton offre/formule te donne de la marge par exemple par rapport à tes estimations (trafique), faire du SQL me semble bien plus simple, et tout aussi rapide sinon plus.

je suis chez 1&1 et j'ai pris le pack pro, je pense que je peux y aller
OK, je comprends qu'il vaut mieux alors faire la conversion de la devise directement dans mysql, c'est ca??

Peu importe, c'est du *_once surtout dont je faisais allusion.
Le *_once sous entend que c'est Php qui gèrera le cas, en cas d'erreur.
...

ah d'accord, je sais seulement que require genere une erreur contrairement au include mais je ne sais pas qu'il fallait eviter le _once.
en est il de meme pour les require "footer.php", "hearder.php", faut il mettre uniquement un require() ??

[RunCodePhp]

OK, je comprends qu'il vaut mieux alors faire la conversion de la devise directement dans mysql, c'est ca??

Le plus simple est quand même d'en avoir la certitude que cette marge soit suffisante.
Le nombre de requêtes simultanées doit être précisée quelque part.
Faire une certaine estimation, et une fois en production avoir un oeil dessus.

en est il de meme pour les require "footer.php", "hearder.php", faut il mettre uniquement un require() ??

Tout ça est plus une vision du comment gérer des cas d'erreurs, et là à chacun de voir les choses.

La mienne, un simple require suffirait, du fait que les probabilités d'erreurs sont très faibles qu'il y ait 2 require.
Si dans le plus grand des hasards il y a erreur, il est théoriquement bon d'en être informé.

Chacun donc sa vision, mais j'adhère tout de même à l'idée qu'il vaut mieux une belle erreur que de faire en sorte de la masquer, c'est juste sur ce point là que je réagit.

[Joker-eph]

A coté de ça, faire un "include_once" d'une part ne sert à rien, de plus, l'approche au problème n'est pas le bon.
Ici, tu fait quelque part tout pour qu'un 2ème fichiers (fr + en par exemple) ne soit pas inclus.
Pourquoi pas.
Mais un "require()" dans l'approche serait mieux, car s'il venait à avoir un bug, donc inclure un 2ème fichier, on tentera de créer une 2ème constante du même nom.
Et bien il est préférable d'être au courant de cette erreur plutôt que ne rien inclure, donc de laisser filer les choses sans encombre.
Pourquoi ?
Et bien qu'est ce qu'il dit que le 1er fichier inclus est le bon ?
Pourquoi ça ne serait pas plutôt le 2ème à inclure et pas le 1er ?
Et bien rien, vois tu ?

Rien à voir, un require exigera le fichier, le once implique juste que le MÊME fichier ne sera pas inclus 2 fois...

Avoir un require_once du français, puis de l'anglais incluera bien les 2 fichiers. Il n'y a donc pas a se poser la question duquel est inclus en premier et de la detection de l'erreur vis à vis du _once ici.

Le _once s'applique parfaitement à tous fichier de configuration justement.

[RunCodePhp]

Rien à voir, un require exigera le fichier, le once implique juste que le MÊME fichier ne sera pas inclus 2 fois...

Avoir un require_once du français, puis de l'anglais incluera bien les 2 fichiers. Il n'y a donc pas a se poser la question duquel est inclus en premier et de la detection de l'erreur vis à vis du _once ici.

Le _once s'applique parfaitement à tous fichier de configuration justement.

Inclure le Français et l'Anglais est justement ce qu'il ne faut pas faire, car l'erreur obtenue ne sera pas dû au require_once, ok, mais du fait qu'on tentera de créer 2 constantes au minimum portant le même nom.

Vu que ce sont des constantes, et bien de manière indirecte il ne pourra pas avoir 2 fois les mêmes constantes, donc forcément l'ordre d'inclusion aura inévitablement une importance.
La 1ère constante définie passera, la 2ème non, Php l'interdira et génèrera une erreur.
Vois tu ?

Ceci dit, tout ça néanmoins un faut problème, car les probabilités qu'il y ai 2 langues ou 2 devises incluses sont réduites à 0, car les inclusions viennent de la session, et la session contiendra 1 seule langue et 1 seule devise.
Il n'y a pas de boucle, pas d'autoload ou autre du même genre.
Un _once devient théoriquement inutile, un require tout court serait tout aussi bien.

Si dans le grand des hasards on venait à inclure 2 fois le même fichier, un require_once ne l'inclura pas, et ne génèrera pas d'erreur.
Par contre, les erreurs sur les constantes vont avoir lieu.
Est ce mieux ?
A mon sens non.

Maintenant, comme je l'ai déjà dit, chacun sa vision fasse aux erreurs éventuels.

[redah75]

wow, je suis un peu perdu
mais sinon coté perf, lequel est le plus rapide??

[Joker-eph]

Inclure le Français et l'Anglais est justement ce qu'il ne faut pas faire, car l'erreur obtenue ne sera pas dû au require_once, ok, mais du fait qu'on tentera de créer 2 constantes au minimum portant le même nom.

Vu que ce sont des constantes, et bien de manière indirecte il ne pourra pas avoir 2 fois les mêmes constantes, donc forcément l'ordre d'inclusion aura inévitablement une importance.
La 1ère constante définie passera, la 2ème non, Php l'interdira et génèrera une erreur.
Vois tu ?

Bien sur, mais tu conseillais d'éviter le _once pour voir l'erreur, ce qui n'est absolument pas pertinent ici : le _once ne changera rien sur la détection de l'erreur, voici mon point ;-)

Si dans le grand des hasards on venait à inclure 2 fois le même fichier, un require_once ne l'inclura pas, et ne génèrera pas d'erreur.

Oui, et c'est tout l'intérêt, en plus des avantages coté performance :-)

Par contre, les erreurs sur les constantes vont avoir lieu.
Est ce mieux ?
A mon sens non.

Quelles erreurs auront lieu sur les constantes ? require_once ne l'incluera pas et il n'y a pas de raison d'avoir d'erreur de redéfinition de constante, je ne vois pas du tout ton point.

[RunCodePhp]

Bien sur, mais tu conseillais d'éviter le _once pour voir l'erreur, ce qui n'est absolument pas pertinent ici : le _once ne changera rien sur la détection de l'erreur, voici mon point

Oui, et non, il y avait pas mal de sous entendus.
Mes explications n'étaient pas très clair je le reconnais.

Dans son cas, il sera impossible d'inclure 2 langues différentes vu que l'inclusion dépend totalement de la session, et que celle ci contient qu'une seule et unique langue.
Un require_once devient totalement illogique, un simple require serait suffisant.
L'idée principale que je voulais dire était d'éviter de mettre systématiquement des _one partout.

Puis après, j'ai mis des explications qui se voulaient assez générales, comme le fait qu'un require_once masque indirectement l'erreur si un fichier est inclus 2 fois à cause d'un bug.
Ce genre de bug peu durer très longtemps avant qu'on s'en aperçoive.
C'est vicelard, encore une fois.
C'est l'idée principale que je voulais évoquer là aussi.

De plus, ici ce sera une fois qu'on aura démasquer le bug qu'on saura si c'était anodin ou que cela consommait beaucoup de ressource.
Donc miser sur les performances comme mettre un require_once n'est pas forcément la meilleur approche.

Puis troquer un require pour un require_once en prenant comme critère les performances, j'ai du mal à adhérer à cette idée.

Pour ma part, le choix est plutôt basé sur le fichier à include, de son contenu, et des conséquences (bug) si le même fichier est inclus 2 fois.
Mieux vaut il laisser filer le script ? (require_once).
Mieux vaut il avoir un plantage ?
Mieux vaut il gérer l'erreur ? (try/catch par exemple) ?

Le choix est plutôt ici, et dans certain cas, un require_once s'impose tout comme à proscrire.

Le _once s'applique parfaitement à tous fichier de configuration justement.

Dans les FrameWork tels que CakePhp, Kohana ou encore Jelix que je prospecte depuis peu, tous utilisent de simples require pour inclure des configs, pour exemple.

Théoriquement, un fichier config doit être inclus qu'une seule et unique fois, surtout pas 2 on va dire.
Là encore un require_once masquera un éventuel bug.
Personnellement, j'en conclu que ces FrameWork utilisent des require pour la même raison, non ?

[Joker-eph]

Dans son cas, il sera impossible d'inclure 2 langues différentes vu que l'inclusion dépend totalement de la session, et que celle ci contient qu'une seule et unique langue.
Un require_once devient totalement illogique, un simple require serait suffisant.

Encore une fois, je ne vois AUCUN rapport entre le fait d'inclure ou non 2 langue différente et le _once...
Le _once intervient en cas d'inclusion de la MÊME langue (même fichier) 2 fois de suite.

Puis après, j'ai mis des explications qui se voulaient assez générales, comme le fait qu'un require_once masque indirectement l'erreur si un fichier est inclus 2 fois à cause d'un bug.
Ce genre de bug peu durer très longtemps avant qu'on s'en aperçoive.

Encore faut-il considérer que ce soit un bug... J'espère que ce n'est pas une "querelle de chapelle" ;-)
Ça m'intéresse, t'as un exemple où utiliser _once sur un fichier de conf peut poser problème en masquant un bug ?

Le choix est plutôt ici, et dans certain cas, un require_once s'impose tout comme à proscrire.

Pour moi il est au contraire parfaitement indiqué pour ce genre de cas :-)

La doc php dit :

"La fonction include_once est utilisée de préférence lorsque le fichier doit être inclus ou évalué plusieurs fois dans un script, ou bien lorsque vous voulez être sûr qu'il ne sera inclus qu'une seule fois, pour éviter des redéfinitions de fonction. "

Théoriquement, un fichier config doit être inclus qu'une seule et unique fois, surtout pas 2 on va dire.
Là encore un require_once masquera un éventuel bug.

Je dirais le require_once assurera cet état de fait, je ne considère pas que se retrouver dans une situation ou on peut rencontrer 2 fois un include du même fichier de conf soit un bug, le _once permet juste de dire "inclue le sauf s'il l'a déjà été", c'est exactement fait pour les fichiers qui définissent des paramètres, des fonctions, ou des classes (encore qu'il y a d'autres méthodes pour ces dernières).

[Joker-eph]

Puis troquer un require pour un require_once en prenant comme critère les performances, j'ai du mal à adhérer à cette idée.

Ah juste un détail : je ne voulais pas mettre ça en avant, parceque ça a toutes les chances d'être complêtement négligeable vis à vis du temps total d'exécution du script, et il y a de toute façon certainement mieux à gagner ailleurs !

[RunCodePhp]

La doc php dit :

La fonction include_once est utilisée de préférence lorsque le fichier doit être inclus ou évalué plusieurs fois dans un script, ou bien lorsque vous voulez être sûr qu'il ne sera inclus qu'une seule fois, pour éviter des redéfinitions de fonction

On ne n'entre pas dans ces cas là, justement.

Dans son cas, il est certain que les fichiers ne seront pas inclus 2 fois car la session ne peut en contenir qu'une, c'est impossible quelle en contienne 2.

De plus, ceci se traduira par une seule ligne de code pour les inclure, une pour la langue, une pour la devise (il n'y aura ni boucle, ni condition, ni d'autoload, etc ...).

Un require() est plus que largement suffisant, donc justifié.
(Idem pour les footer.php, hearder.php)


Quasi tous les FrameWork font comme ça, et c'est parfaitement justifié, je ne vois aucune raison dans son cas de faire autrement ...

Ça m'intéresse, t'as un exemple où utiliser _once sur un fichier de conf peut poser problème en masquant un bug ?

Explique moi plutôt pourquoi un _once se justifierait pour un fichier qui ne pourra jamais être inclus 2 fois.
... Comme les CakePhp, Kohana, Jelix, etc ... (je peux en citer plein d'autres, suffit d'y aller pour le vérifier) qui utilisent essentiellement des require plutôt que des _once pour des configs.

Ah juste un détail : je ne voulais pas mettre ça en avant

Ok, mais les divers hypothèses que j'ai évoqués jusqu'à lors avaient pour but d'expliquer la différence entre un require et un require_once.

Il ne fallait pas prendre ces exemples pour "argent comptant" mais juste tenir compte entre autre de l'effet pervers que provoque le _once si on l'utilise de manière inconsidérée.
C'est un peu comme mettre des @ devant des fonctions, donc au bout ne jamais être au courant d'un éventuel bug.

Un _once masque indirectement l'erreur si c'est un bug et non une ré-évaluation volontaire, c'est un aspect à savoir.
Ne jamais être au courant d'un bug est contraire à toute logique.

[Joker-eph]

On ne n'entre pas dans ces cas là, justement.

Pour moi la partie en gras colle exactement... m'enfin...

Il ne fallait pas prendre ces exemples pour "argent comptant" mais juste tenir compte entre autre de l'effet pervers que provoque le _once si on l'utilise de manière inconsidérée.
C'est un peu comme mettre des @ devant des fonctions, donc au bout ne jamais être au courant d'un éventuel bug.

J'attends toujours un seul exemple qui justifie qu'on puisse laisser passer un bug comme ça...

[RunCodePhp]

Pour moi la partie en gras colle exactement... m'enfin...

Le plus intéressant serait de dire sur quel critère tu te base qu'on entrerait dans ce cas là.

Dans son cas, il n'y pas à vouloir que ce soit inclus qu'une seule fois pour la simple raison que ça le sera obligatoirement.
C'est impossible qu'il y ait 2 langues ou 2 devises, au même titre qu'il n'y aura jamais 2 lignes de codes incluant 2 fois la même langues ou devise.
- 1 variable de session de langue = 1 langue (fr)
- 1 variable session de devise = 1 devise (euro)
Comment faut il le dire ?
C'est quand même pas compliquer à comprendre ça tout de même, non ?

Le seul bug possible, c'est que la langue n'existe pas (ce qui n'est plus du tout la même chose).
Et encore, la (bonne) logique sera de tout faire pour en initialiser une, celle par défaut.
Donc au pire (la vrai grosse cata), si la session ne contient pas une langue, ce n'est même pas la peine de continuer le script, tout le reste va inévitablement s'écrouler, y compris le require (once ou pas).
Un try/catch serait à envisager, entre autre.


Il faut donc voir ce qui se dit dans la doc concernant le require (tout court).

require() est identique à include() mise à part le fait que lorsqu'une erreur survient, il produit également une erreur fatale de type E_COMPILE_ERROR. En d'autres termes, il stoppera le script alors que include() n'émettra qu'une alerte de type E_WARNING, ce qui permet au script de continuer.

Et bien ça, c'est parfait.
Scénario catastrophe à comparer à un incendie, si on peu dire.

Comme dans notre cas le seul bug possible sera de tenter d'inclure une langue (toujours 1 seule) qui n'existerait pas, donc que tout partirait totalement en sucette, et bien que le script soit stopper au require() (vraiment pire des cas) sera une aubaine.


C'est de cette même logique qu'adoptent les FrameWork dont j'ai cité.
Pourquoi donc font ils comme ça alors, (des require et non des _once) ?
D'ailleurs, il faudrait que tu les contact, car ils feraient fausses route, non ?

J'attends toujours un seul exemple qui justifie qu'on puisse laisser passer un bug comme ça...

Il n'y aura pas de bug à ce niveau, c'est impossible (encore une fois).

J'attends toujours que tu me dise ce qui justifie un _once quand un fichier ne sera jamais inclus 2 fois.

Que je sache, c'était tout de même l'origine de ton inversion.
Jusqu'à lors j'en sais toujours pas plus, et ça se peu qu'on soit 2.


Pour ma part, tu ne fais que contredire sans jamais prendre le temps d'expliquer pourquoi, comment, ni d'idées, ni d'arguments ... ou tellement peu qu'il est impossible d'adhérer à quoi que soit.
Pour qu'on puisse voir qu'on est dans l'erreur, c'est pas tout de le dire, faut que ça repose sur quelque chose, une logique (qui soit logique), un minimum quoi.

[Joker-eph]

Le plus intéressant serait de dire sur quel critère tu te base qu'on entrerait dans ce cas là.

Dans son cas, il n'y pas à vouloir que ce soit inclus qu'une seule fois pour la simple raison que ça le sera obligatoirement.
C'est impossible qu'il y ait 2 langues ou 2 devises, au même titre qu'il n'y aura jamais 2 lignes de codes incluant 2 fois la même langues ou devise.
- 1 variable de session de langue = 1 langue (fr)
- 1 variable session de devise = 1 devise (euro)
Comment faut il le dire ?
C'est quand même pas compliquer à comprendre ça tout de même, non ?

T'es hors sujet, je répète pour la 3ème fois : le "_once" n'a AUCUNE influence sur le fait d'avoir 2 langues différentes incluse à la fois puisque ce sont 2 fichiers différents.

J'attends toujours que tu me dise ce qui justifie un _once quand un fichier ne sera jamais inclus 2 fois.

Que je sache, c'était tout de même l'origine de ton inversion.
Jusqu'à lors j'en sais toujours pas plus, et ça se peu qu'on soit 2.

Mon intervention était : le _once est fait pour ça selon la .doc :
"lorsque vous voulez être sûr qu'il ne sera inclus qu'une seule fois, pour éviter des redéfinitions de fonction".
Par définition on veut être sur que ce fichier ne soit inclus qu'une seule fois non ? Le _once n'est pas injustifié... Désolé mais je vois mal comment tu peux contredire ça !

Pour ma part, tu ne fais que contredire sans jamais prendre le temps d'expliquer pourquoi, comment, ni d'idées, ni d'arguments ... ou tellement peu qu'il est impossible d'adhérer à quoi que soit.
Pour qu'on puisse voir qu'on est dans l'erreur, c'est pas tout de le dire, faut que ça repose sur quelque chose, une logique (qui soit logique), un minimum quoi.

Exactement : tu rejètes le _once sur un seul et unique argument de "bug qui ne serait pas détecté", mais quand je te demande de développer ou de donner un exemple... néant
Désolé mais pour l'instant je ne vois toujours pas d'argument pour ne pas utiliser le _once !

[RunCodePhp]

Houlala, ça commence à me fatiguer cette histoire

T'es hors sujet, je répète pour la 3ème fois : le "_once" n'a AUCUNE influence sur le fait d'avoir 2 langues différentes incluse à la fois puisque ce sont 2 fichiers différents.

Amen !!!
Je le sait, et on s'en fiche comme de l'an quarante.
Je viens de le dire :

C'est impossible qu'il y ait 2 langues ou 2 devises, au même titre qu'il n'y aura jamais 2 lignes de codes incluant 2 fois la même langues ou devise.

Donc dans les 2 cas c'est impossible, donc y compris d'inclure 2 fois la même.
Le risque est à 0, jamais de bug sur ce point.
Je ne cesse de le dire depuis le tout début, il faut quand même lire.

A partir du moment où on a qu'1 seul et unique fichier à inclure, c'est un require qu'on utilise.
Ca ne va pas plus loin que ça.
Un _once devient naturellement inutile.
Comme il est inutile de rajouter un code ou instruction inutile, et bien on ne le rajoute pas.
Ca coule de source.

Désolé mais pour l'instant je ne vois toujours pas d'argument pour ne pas utiliser le _once !

Il est dans la session, entre autre.
Et comme je viens de le dire à l'instant : Il est inutile de rajouter quelque chose d'inutile, en toute logique.

Le _once n'est pas injustifié... Désolé mais je vois mal comment tu peux contredire ça !

Télécharger au moins 1 FrameWork et regarder comment ils font.


Ca sera mon mot de fin, car là, je sature.

[Joker-eph]

Dommage d'avoir peut être des idées mais de ne pas être capable de les présenter. J'aurai bien aimé voir un exemple de ces fameux "bug non détectés" que tu vantes si bien

[RunCodePhp]

Dommage d'avoir peut être des idées mais de ne pas être capable de les présenter. J'aurai bien aimé voir un exemple de ces fameux "bug non détectés" que tu vantes si bien

Un banal copier coller d'un require_once par exemple, donc faire la "bourde" de la mettre 2 fois.
Au bout, on ne sera pas au courant du bug vu qu'il n'y aura pas 2 inclusions du fichier, mais surtout aucun retour d'erreur.
Donc bug non détecté ici car la 2ème ligne est quant même évaluée par Php, ça occupe de la ressource, même minime.
Si on ne voit pas cette double ligne/bug, elle peu rester là des jours, mois, années.
(Ca aussi ça fait je ne sais combien de fois que je le dis, il ne faut pas se contenter d'attendre des explications, il faut essayer, même le truc le plus bateau voir idiot).

Ici, un require tout court est une aubaine, car ça va provoquer une erreur fatale, donc on sera averti du bug.
Question : Faut il prévoir ce genre de "bourde" dans son code ?
- La réponse est en toute logique : non, même surtout pas, pas de _once (donc à proscrire).
- Au même titre que lorsque ce n'est pas utile de le mettre, et bien on ne le met pas.
- D'ailleurs, un require_once() est moins performant qu'un require (tout court), ce qui fait une raison de plus.
Ca fait au total 3 raisons (ou arguments) qui ne justifie pas de _once dans son cas ...
C'est la même politique qu'appliquent quasi tous les FrameWork, il suffit d'aller jeter un oeil.
Finalement ça en fait 4.
( vais finir par devenir bègue )


Le cas/bug ici est bateau, l'erreur anodine, certes (c'est pour faire court), mais il est bien là quand même.
Je te laisse imaginer un autre scénario tout aussi bateau où cette fois les conséquences seraient plus graves.
Si tu n'a pas assez d'imagination, et bien tans pis.


Pas capable, pas capable ... ça fait 3 pages entières, pleins d'idées en tout genre rien que pour ce topic.
De ton coté, pas l'ombre d'une idée, rien, nada, sinon que de contredire sans argument.
C'est plutôt toi qui n'est pas capable de me comprendre tu veux dire.

Relis toi, tu ne fais que bâtir ton choix sur une seule et unique remarque dans la doc, qui n'est rien d'autre qu'une (mauvaise) interprétation.
Dans d'autre domaines, je ne t'explique pas les dégâts que font les mauvaises interprétations.

Personnellement, je ne suis qu'un amateur, ça va encore, je m'en fiche un peu, mais faire ceci avec quelqu'un qui serait un pro avec de la bouteille, de l'expérience, ça devient "lourdingue", tu ne crois pas ?

Moi je dis qu'il n'y a pas pire sourd qui ne veut pas l'entendre.

[Joker-eph]

Un banal copier coller d'un require_once par exemple, donc faire la "bourde" de la mettre 2 fois.

Je suis impressionné par le coté "vicelard" du bug, des heures de débug en perspective !!

Donc bug non détecté ici car la 2ème ligne est quant même évaluée par Php, ça occupe de la ressource, même minime.

Qui a jugé stupide de se basé sur la performance ? ;-)

Question : Faut il prévoir ce genre de "bourde" dans son code ?
- La réponse est en toute logique : non, même surtout pas, pas de _once (donc à proscrire).

Réponse stupide, tu adores les frameworks ? Fait grep require_once et include_once dans le code...

- D'ailleurs, un require_once() est moins performant qu'un require (tout court), ce qui fait une raison de plus.

Je suis impressionné par la puissance de l'argument, tu me fais la mesure qu'on rigole ? ;-)
(attention va falloir taper dans les compteurs hardware pour la mettre en évidence sur un require )

Je te laisse imaginer un autre scénario tout aussi bateau où cette fois les conséquences seraient plus graves.
Si tu n'a pas assez d'imagination, et bien tans pis.

Ahaha mort de rire, c'est toi qui annonce depuis une page qu'il y a un grand danger sans pouvoir justifier... peut-être que tu va finir par accepter que ça ne sort que de ta tête ?

Relis toi, tu ne fais que bâtir ton choix sur une seule et unique remarque dans la doc, qui n'est rien d'autre qu'une (mauvaise) interprétation.

C'est toi qui le dit...

Personnellement, je ne suis qu'un amateur, ça va encore, je m'en fiche un peu, mais faire ceci avec quelqu'un qui serait un pro avec de la bouteille, de l'expérience, ça devient "lourdingue", tu ne crois pas ?

Un amateur qui m'a l'air plus sur de soi et hautain qu'un vrai pro !

Bon allé sans rancune, on va en rester là, tu m'as assez fait perdre de temps en fait, je n'aurai finalement rien appris de particulier, ni découvert de super bug...