Discussion :

[Papy214]

Bonjour,

Je sais à quoi sert le mot clé global mais ce que je cherche à savoir, c'est que fait cette "instruction" exactement en interne ?

Par exemple, si j'ai 3 fonctions dans une classe et que chacune utilise un tableau de valeurs défini dans un autre module de code, j'utilise global dans les 3 fonctions pour avoir accès au tableau.

Que fait php ? une copie du tableau à chaque utilisation ? juste un lien vers le tableau ?

Plus généralement, est-il plus couteux en performance d'utiliser global plusieurs fois ou vaut-il mieux passer le tableau en paramètre de chaque fonction qui utilise l'élément mis en global ?

Papy !

[sabotage]

La question est interessante.

Mais dans le cas d'une class, tu peux utiliser $this pour utiliser des variables dans des fonctions.

Sinon en dehors des classes si tu connais a l'avance le nom de ta variable, effectivement tu peux utiliser "global" plutot que de passer un paramètre.

[metagoto]

global fait la même chose qu'un assignement par référence. Il n'y a pas de copie de la variable. En interne, php utilise les mêmes instructions (op code).

Utiliser global sera grosso-modo la même chose qu'un passage par référence en terme de perf:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
function a() {
  global $var;
}
 
function b(&$var) {
}

php fait du copy-on-write, c'est à dire qu'un passage par copie (ou par valeur) n'entraine une réelle copie que lorsque les valeurs des variables divergent. Il est recommandé de passer par valeur sauf lorsqu'on a réellement besoins d'un passage par référence.

Dans un cadre OOP, le mot clé global tend à être évité comme la peste. Celui-ci entraine un couplage trop fort avec le reste du script (le global scope). Recourir à des singletons, histoire de se donner bonne conscience, revient à la même chose: c'est un global déguisé.

[RunCodePhp]

Salut

Effectivement, le topic est très intéressant.
Il me semble qu'on doit être très nombreux à se poser la même question :
Faut il exploiter/déclarer une variable global ?
Ou plutôt un passage en paramètre ? (par référence ou pas d'ailleurs).
Ou plutôt exploiter un singleton (pour un objet), même si c'est symbolique ?

En tout cas, je me la suis poser, et je me la pose encore cette question.
J'ai pas vraiment de réponse, à part une intuition, me dire que le choix que j'ai fais serait le mieux adapté, ou correspond à ce que j'attends.

Dans mes souvenir lointain, il me semble avoir lu qu'une déclaration comme global, de même qu'exploiter le tableau super global $GLOBAL manquerait de sécurité.
Je n'ai plus du tout souvenir des raisons. Je me demande s'il n'y aurait pas confusion.
Est ce vrai ?
Et si c'est vrai, pour quelle raison, dans quel cadre ?


Toujours est il qu'il me semble faire comme beaucoup, soit ne plus utiliser de déclaration global, mais préférer des singletons ou autre.
Donc pour la POO, et même si un singleton est symbolique (un global déguisé), et sans une vrai raison bien fondée, je préfère l'injecter de manière explicite (donc très forte dépendance entre 2 classes) que d'utiliser un global.


En tout cas, j'ai remarqué que si on abuse un peu du global, au bout, et surtout avec le temps, on perd un peu la maitrise de son projet, et les "effets de bords" nous guettent à chaque tournant.
Un simple changement de nom sur une variable globale, et patatras, nous voilà avec un sapin de Noël en guise de site Web.
Ou pire, on constate (encore faut il le constater) que la valeur d'une variable n'a pas du tout la valeur attendue. Normal, celle ci est modifiée en court de route dans une fonction ou autre classe entre temps, et on passe un temps fou à savoir ou, et quand.
Je ne parle même pas du cas où on crée accidentellement 2 variables du même nom, et que l'une est global et modifiée dans une fonction ou autre ... des coups à balancer son PC par la fenêtre.
Bref ... utiliser des variables globales, pourquoi pas, mais faut pas abuser.

[Papy214]

Donc, coté perf, pas de différence mais pas assez POO ...

Coté perf, je ne savais pas, mais cote POO j'étais déjà d'accord

Merci de vos avis !

[Petibidon]

Faut il exploiter/déclarer une variable global ?
Ou plutôt un passage en paramètre ? (par référence ou pas d'ailleurs).
Ou plutôt exploiter un singleton (pour un objet), même si c'est symbolique ?

Tout dépend comment tu l'utilises. Si tu l'utilises dans une petite fonction créée au cours du code pour te simplifier la vie sur un point quelconque, sans idée de réutiliser cette fonction à un autre moment, alors oui, tu peux utiliser global. L'inconvénient qu'on peut y trouver, c'est à la relecture du code si le nom de la variable est peu parlant ou si tu n'as pas commenté correctement.
Comme souvent global rime avec fonction faite à l'arrache, le commentaire est souvent négligé.

Dans mes souvenir lointain, il me semble avoir lu qu'une déclaration comme global, de même qu'exploiter le tableau super global $GLOBAL manquerait de sécurité.
Je n'ai plus du tout souvenir des raisons. Je me demande s'il n'y aurait pas confusion.
Est ce vrai ?
Et si c'est vrai, pour quelle raison, dans quel cadre ?

Y'a pas vraiment de problème de sécurité. Le seul truc c'est que ça rend une fonction entièrement dépendante du code procédural. Si tu fais n'importe quoi avec la variable dans ton code procédural, tu auras une fonction qui marchera peut-être une fois, et plus au deuxième appel. Vas trouver pourquoi

Toujours est il qu'il me semble faire comme beaucoup, soit ne plus utiliser de déclaration global, mais préférer des singletons ou autre.
Donc pour la POO, et même si un singleton est symbolique (un global déguisé), et sans une vrai raison bien fondée, je préfère l'injecter de manière explicite (donc très forte dépendance entre 2 classes) que d'utiliser un global.

Attention également avec cette mode du singleton. On voit souvent des méthodes de classe faire des appels "truc::getInstance()"... Super.
Et si tu veux réutiliser ta classe ailleurs ?
Tu seras obligé de réutiliser "truc". Même si cette classe n'a aucun intérêt pour ce que tu veux faire.
Ou alors modifier ta classe pour retirer les appels à "truc".
Ou encore recréer une classe "truc" pour l'occasion.
Pratique n'est ce pas ?

[RunCodePhp]

Attention également avec cette mode du singleton. On voit souvent des méthodes de classe faire des appels "truc::getInstance()"... Super.
Et si tu veux réutiliser ta classe ailleurs ?
Tu seras obligé de réutiliser "truc". Même si cette classe n'a aucun intérêt pour ce que tu veux faire.
Ou alors modifier ta classe pour retirer les appels à "truc".
Ou encore recréer une classe "truc" pour l'occasion.
Pratique n'est ce pas ?

C'est exactement ce que je fait.
Disons que cette mode des singletons, j'suis tomber dedans, mais alors, de la tête aux pieds

Par contre, je ne parviens pas à voir les inconvénients que tu décris.
Comme par exemple, Truc est utilisée ailleurs, et ça ne cause pas de problème.
Ceci dit, j'ai remarqué que l'ordre des instanciations avait une importance.
L'une doit être faite avant l'autre parce que l'autre à besoin de l'une.
Et ainsi de suite.

Par moment, certaines classes ont besoin faire appel à 1 seule méthode d'une autre classe.
L'injecter me semble la solution la plus propre, peu importe la forte dépendance.
Mais là où ça fait bizarre, c'est qu'il y a par moment 3, 4, 5 injections de classes pour une classe donnée.
M'enfin ...

Mais que faire d'autres ?
Je ne vois pas.
Déporter les traitements ailleurs ? Faire une autre classe ?
Ca me semble pas une bonne solution.
Ca risque de faire des fonctions ou classes "fourre tout".

Toujours est il que tout ceci est vraiment lié à la portée, visibilité, etc ... (global bien souvent)
Un peu compliqué tout ça n'empêche

@Petibidon
D'ailleurs, soit dit en passant ...
Ta solution (je ne sais dans quel topic) où tu proposais une solution avec un verrou, je l'ai adoptée
Je l'ai trouvée vachement bien comme solution.
Du moins, ça me conviens très bien. Merci au passage