Discussion :

[FrontLine]

Bonjour,

je cherche à utiliser certaines variables n'importe où dans mon script (classe et fonction notamment), c'est pourquoi je me demande quel est la meilleure solution en terme de sécurité et de performance :

- global : c'est ce que je fais actuellement mais bon faire un global $var1, $var2, $var3 dans toutes les fonctions et méthodes laisse à désirer.

- $globals : jamais utilisé, quel est votre avis ? A éviter niveau sécurité ou performance ?

- $_SERVER['mavar'] : j'hésite à placer mes variables globales dedans mais le fait qu'on le voit dans le phpinfo() me refroidit

- Une fonction_static('mavar', 'valeur') : un peut lourd comme solution pour garder 2 ou 3 valeurs nécessaires au fonctionnement de l'application.


Que me conseillez vous svp ?

En vous remerciant par avance.

[juninho269]

moi à ta place j'utiliserai $Global.
Comme sa tu met toutes tes variables dans un autre fichier et tu sauvegarde toutes tes variables dans ce tableau associatif. Niveau performance il n'y a aucun problème, ce n'est qu'un tableau

[s.n.a.f.u]

Et des constantes ?

[FrontLine]

Merci pour vos réponses.

moi à ta place j'utiliserai $Global.
Comme sa tu met toutes tes variables dans un autre fichier et tu sauvegarde toutes tes variables dans ce tableau associatif. Niveau performance il n'y a aucun problème, ce n'est qu'un tableau

Tu veux dire $globals ? Si c'est le cas, je penche aussi vers cette solution, j'attends de voir plus d'infos défois qu'il y ait un effet indésirable propre à PHP.

Et des constantes ?

J'ai besoin de modifier certaines valeurs occasionnellement.

[FrontLine]

Y a t-il du monde qui utilise $globals ?

[s.n.a.f.u]

Ce que je fais dans ce cas :
- je créée un objet avec tous les attributs souhaités
- j'utilise le mot-clé global sur ce seul objet

par exemple, j'utilise cette technique lorsque j'ai besoin d'accéder à mon instance de base de données.
C'est lourd de mettre ça dans toutes les fonctions ?
D'une part, pas dans toutes, et d'autre part, combien d'architectures foireuses et tordues auraient pu être évitées si les développeurs n'avaient pas peur de coder un peu ?...

[kaymak]

pourquoi passer par global quand on à disposition les possibilités de la porgrammation orientée objet ?
Une propriete static ce n'est pas un peu plus clean ? voir un singleton..

Perso c'est ce que je ferais, une classe, avec pour les moments mes options coder en dur (si il y'en à que 3...) puis le jour ou j'ai besoin d'en mettre beaucoup, ou bien d'ajoutr quelques regles metier. Pas de souci, je modifie la classe d'option. Et voila.

[s.n.a.f.u]

pourquoi passer par global quand on à disposition les possibilités de la porgrammation orientée objet ?
Une propriete static ce n'est pas un peu plus clean ? voir un singleton..

Perso c'est ce que je ferais, une classe, avec pour les moments mes options coder en dur (si il y'en à que 3...) puis le jour ou j'ai besoin d'en mettre beaucoup, ou bien d'ajoutr quelques regles metier. Pas de souci, je modifie la classe d'option. Et voila.

Propriété statique ou utilisation de "global", ça revient grosso modo au même.
Le singleton n'est pas un remplacement, ce ne serait qu'une couche en plus.

Franchement, l'idéal c'est carrément de la passer en paramètre. Même si c'est le plus contraignant.

Mais nous sommes d'accord sur le point le plus important : une classe de config et avec plusieurs moyens de l'utiliser ensuite.

[FrontLine]

Bonjour

merci pour vos réponses.

Une classe d'option en pratique c'est bien beau et plus élégant mais inutile pour le serveur d'étendre à chaque fois une classe static uniquement pour mettre quelques variables de config.

La POO c'est bien, en abuser ça craint

En paramètre idem, je vais pas mettre à chaque fois : $site_nom, $site_url, $admin_email, $admin_nom, $iscache, ...

C'est augmenter ma charge de travail ainsi que celle de mon serveur pour rien.


Du coup après avoir fais le tour de la question, je ne vois que la solution de créer un tableau et de le charger à l'intérieur des classes et fonctions avec $globals['tabconfig']['admin_nom']

[s.n.a.f.u]

La POO c'est bien, en abuser ça craint

Voui

En paramètre idem, je vais pas mettre à chaque fois : $site_nom, $site_url, $admin_email, $admin_nom, $iscache, ...
C'est augmenter ma charge de travail ainsi que celle de mon serveur pour rien.

La tienne oui, la charge de ton serveur, sûrement pas ! Je suis quasi sûr que c'est plus performant que l'utilisation de $globals.
On en revient au programmeur et à son courage...

[FrontLine]

La tienne oui, la charge de ton serveur, sûrement pas !

Si si la charge du serveur aussi (en tout cas l'utilisation de la mémoire), c'est minime mais autant ne pas gaspiller ^^

Je suis quasi sûr que c'est plus performant que l'utilisation de $globals.

$globals['toto'] est plus gourmand qu'une variable ($toto) normale ?

[s.n.a.f.u]

Si si la charge du serveur aussi (en tout cas l'utilisation de la mémoire), c'est minime mais autant ne pas gaspiller ^^

Je ne vois pas en quoi l'utilisation de la mémoire change.
Et tu as raison, c'est minime. Ca ne sert pas à grand chose, si ce n'est compliquer le code.

$globals['toto'] est plus gourmand qu'une variable ($toto) normale ?

En soi, non ou pas grand chose. Mais niveau résolution de portée, c'est plus couteux.

[kaymak]

Bonjour
Une classe d'option en pratique c'est bien beau et plus élégant mais inutile pour le serveur d'étendre à chaque fois une classe static uniquement pour mettre quelques variables de config.

La POO c'est bien, en abuser ça craint

Oui, je suis d'accord qu'en abuser c'est pas forcément interessant (quoique dotnet.... bref). Mais dans ce cas là je consièdre que c'est prendre en compte une évolution future, qui à de forte chance de se voir réaliser.
Je sais que l'on ne code pas pour ce que l'on pourrait eventuellement faire. Mais là c'est tellement simple, et c'est je pense, s'éviter tellement de galère par la suite en cas de maj que perso j'opte pour rajouter une couche de controle plutot que d'utiliser des variables directement.

Soit dit en passant, j'ai propose une classe, m'enfin la même chose ne procédural est plus que possible.

concernant la charge du serveur........... C'est vraiment peanut la, j'oserais même un <Nan mais, t'es sérieux là ?!>.

bye

[s.n.a.f.u]

...<Nan mais, t'es sérieux là ?!>.

+1

[FrontLine]

Oui je suis sérieux, si je peux économiser des conso de ressources inutiles par ci par là, je me sent mieux à l'intérieur et ça se voit à l'extérieur

Après c'est vrai que prévoir l'évolution dans un sens imprévisible c'est pas plus mal, je vais méditer sur ce point au niveau de mon tableau de config ou ma classe je sais pas encore vers quoi je vais me pencher.

Merci d'avoir pris la peine de répondre

EDIT : j'ai opté pour une classe de config qui est accessible de partout ( ClassConfig::$var['plop'] ), ça augmente de 30ko la mémoire mais tellement plus maniable