Que fait global ?

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 !

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.

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:

---

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é.

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. :cry:
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. :mrgreen:
Bref ... utiliser des variables globales, pourquoi pas, mais faut pas abuser. ;)

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 !

Citation:

---

Envoyé par RunCodePhp

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é.

Citation:

---

Envoyé par RunCodePhp

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 ;)

Citation:

---

Envoyé par RunCodePhp

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 ?

Citation:

---

Envoyé par Petibidon

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 :mrgreen:

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 :D
Je l'ai trouvée vachement bien comme solution.
Du moins, ça me conviens très bien. Merci au passage :ccool:

Citation:

---

Envoyé par RunCodePhp

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.

---

C'est justement un des problèmes que l'on voit souvent. On programme une classe A tout en pensant qu'elle devra s'appuyer sur B pour fonctionner. Du coup cette classe A est dépendante de B, et devra fournir des méthodes pour gérer B. Une modification dans B risque d'entraîner des modifications dans A, etc.

Un des intérêts de programmer OO est de se concentrer sur une seule problématique à la fois.

Citation:

---

Envoyé par RunCodePhp

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".

---

C'est là qu'entrent en jeu certains design patterns (et qu'on sort du sujet initial :D) tels que commande ou visitor, qui permettent de séparer les problématiques très facilement, au prix par contre d'un code un peu plus verbeux généralement.

Citation:

---

Envoyé par RunCodePhp

@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 :D
Je l'ai trouvée vachement bien comme solution.
Du moins, ça me conviens très bien. Merci au passage :ccool:

---

Content que ça ait pu servir :)
Même si j'aime pas les Singletons :P

Citation:

---

C'est là qu'entrent en jeu certains design patterns (et qu'on sort du sujet initial )

---

Ca s'peut :aie:

Citation:

---

C'est là qu'entrent en jeu certains design patterns (et qu'on sort du sujet initial ) tels que commande ou visitor, qui permettent de séparer les problématiques très facilement, au prix par contre d'un code un peu plus verbeux généralement.

---

Franchement, je vais te dire que tout est relatif, et ça dépend du projet.
Le mien, c'est pas facebook, MicroS*, GG ou je ne sais quel site Web avec un trafique de malade, et des services de dingue.
C'est un projet à l'échelle d'1 personne, donc très modeste.
Du coup, s'il y a de forte dépendance entre les classes ça ne me gène pas, du moins pas pour le moment.
Et puis il y a le problème des connaissances, je n'en ai pas suffisamment pour comprendre les Design Patern, pas à ce niveau là (et encore moins m'en créer un).


En faite, on fait c'qu'on peu ;)
Donc les singletons, ça me satisfait pleinement, et ça me semble bien plus propre que des variables globales en série.
Un de ces 4 je réviserais peut être mon jugement, et hop, ça sera reparti pour 1 tour pour des modifs. ;)

Citation:

---

C'est justement un des problèmes que l'on voit souvent. On programme une classe A tout en pensant qu'elle devra s'appuyer sur B pour fonctionner. Du coup cette classe A est dépendante de B, et devra fournir des méthodes pour gérer B. Une modification dans B risque d'entraîner des modifications dans A, etc.

---

Si on prend PDO par exemple, même si ce n'est pas un singleton, et même s'il n'y a pas une injection de dépendance très forte comme je le fait, PDO est tout de même assez dépendant de la classe Exception, du fait qu'il l'implémente.
Une modif dans Exception sans tenir compte de PDO et voilà que ça déconne.

Ceci dit, la dépendance entre classe c'est un problème, et j'ai du mal à voir comment l'éviter, du moins, mieux que je ne le fait actuellement.

partant d'une simple question, j'ai appris un peu plus et apprécié vos idées.

Merci