Discussion :

[fredrik]

Bonjour à tous,

je cherche à déclarer une nouvelle variable membre dans un objet, dynamiquement, c'est à dire en fonction de la sortie d'un script qui va vérifier si une nouvelle table n'a pas été créée et si cette nouvelle table n'est pas un nouvel attribut de cet objet.
Ca éviterait d'avoir à rajouter du code à chaque modif de la base.

J'ai essayé avec eval et en toute logique ça ne marche pas. Existe t'il une fonction prévue pour modifier le "schéma" d'une classe?


Bonne journée,
A plus,
Frédéric

[Fladnag]

PHP5 ou PHP4 ?

avec PHP5 tu as acces au methodes magiques __get et __set te permettant de gerer des variables membres de maniere transparente pour l'exterieur et de les gerer sous forme de tableau associatif a l'interieur de la classe.

un exemple est présent dans la doc :

http://fr2.php.net/manual/fr/languag...verloading.php

en php4, rien ne t'empeche de "simuler" ce comportement mais les methodes d'acces aux variables ressemblerons a $obj->get('nom_variable'); et $obj->set('nom_variable', $valeur) au lieu de $obj->nom_variable et $obj->nom_variable = $valeur

[Invité]

PHP5 ou PHP4 ?

avec PHP5 tu as acces au methodes magiques __get et __set te permettant de gerer des variables membres de maniere transparente pour l'exterieur et de les gerer sous forme de tableau associatif a l'interieur de la classe.

un exemple est présent dans la doc :

http://fr2.php.net/manual/fr/languag...verloading.php

La surcharge objet n'est pas destinée à gérer les variables et méthodes membres de manière transaprente, sur certaines configurations PHP 5, les méthodes __get et __set ne sont appelées que lorsque la variable membre n'est pas définie dans la classe (ceci devrait être le fonctionnement normal de ces méthodes !).

C'est une grosse aberration du langage qu'il faut cesser de répandre...!!

Le manuel PHP est clair à ce sujet :

Les appels de méthodes et l'accès aux membres peuvent être surchargés via les méthodes __call(), __get() et __set(). Ces méthodes ne seront déclenchées que si votre objet, hérité ou non, ne contient pas le membre ou la méthode auquel vous tentez d'accéder.

Ces méthodes sont destinées à la surcharge, et à la surcharge uniquement.

Utilisez plutôt des accesseurs pour gérer les attributs avec une visibilité limitée (protected ou private).

[Fladnag]

je suis bien d'accord, c'est pas fait pour, mais ca fonctionne... c'est une architecture dynamique pas tres propre, il vaudrait mieux gerer ca explicitement sous forme de tableau avec des setVar($nomVariable, $valeur), mais ca répondais a sa question...

[Invité]

je suis bien d'accord, c'est pas fait pour, mais ca fonctionne... c'est une architecture dynamique pas tres propre, il vaudrait mieux gerer ca explicitement sous forme de tableau avec des setVar($nomVariable, $valeur), mais ca répondais a sa question...

Effectivement ça marche, mais pas systématiquement.

La méthode __call() pour les méthodes ne peut pas être détournée de cette façon, les deux autres devraient suivre...

[Fladnag]

mais je me suis bien gardé de parler de __call, uniquement de __set et __get ;o)

personnellement, j'ai *l'habitude* d'avoir une vision "Java" d'un objet, avec des getter et des setter explicites et des attributs private... donc j'utilise jamais __set et __get

[Invité]

mais je me suis bien gardé de parler de __call, uniquement de __set et __get ;o)

personnellement, j'ai *l'habitude* d'avoir une vision "Java" d'un objet, avec des getter et des setter explicites et des attributs private... donc j'utilise jamais __set et __get

__call() c'est le bon exemple de surcharge PHP. Ca ne marche que pour faire de la surcharge, et c'est pour cela que je l'ai cité. (Ce n'est pas encore le cas pour __get et __set, méthodes de la même "famille").

Tu as la bonne habitude, car __set et __get n'ont jamais été prévus pour gérer des attributs de manière transaprente, c'est un fausse idée à bannir.

Les développeurs PHP ne cessent de le rappeller dans les bugs reports. Ils disent "Ceci n'est pas un bug, consultez le mauel PHP". Et pour cause.

Maintenant la problèmatique est la suivante : Base entièrement un programme sur ce principe "de transaprence" avec __get et __set : Si tu tombes sur un serveur où pour X raisons ça ne marchera pas (je ne connais pas encore la configuration PHP 5 révélatrice) :

Tu es parti pour modifier une à une toutes les variables private ou protected que tu as appellé ou affecté dans un contexte extérieur à celui de la classe. (A moins de déclarer tous les attributs public, mais c'est une autre aberration) résultat :

C'est un cadeau empoisoné !

...

[Fladnag]

Maintenant la problèmatique est la suivante : Base entièrement un programme sur ce principe "de transaprence" avec __get et __set : Si tu tombes sur un serveur où pour X raisons ça ne marchera pas (je ne connais pas encore la configuration PHP 5 révélatrice) :

Tu es parti pour modifier une à une toutes les variables private ou protected que tu as appellé ou affecté dans un contexte extérieur à celui de la classe. (A moins de déclarer tous les attributs public, mais c'est une autre aberration) résultat :

C'est un cadeau empoisoné !

Vu comme ca c'est sur, je ne connais pas toutes les directives de configuration (bah oui, lire la doc ca va, mais les listes rébarbatives dont on se sert tout les 32 févriers, boaf ;o) et n'avais jamais entendu parlé de cas comme cela, je suis donc d'accord, si ce n'est pas une solution portable, qu'il faut l'eviter ;o)

[fredrik]

Bonjour à vous deux,

je débute en prog, alors j'essaie de résumer ce que j'ai compris de votre discussion et de la page de manuel :

pour accéder aux variables membres d'une classe : j'ai 2 possibilités :

1. public : à "bannir" si l'on veut un contrôle à l'entrée
2. méthodes setter et getter à définir soi-même, sûr mais peu flexible

J' ai un peu de mal à comprendre le rôle des méthodes __set et __get. Je comprendrais si elle jouait le rôle d'accesseurs par défaut : on définirait un setter et un getter pour chaque membre et au cas où aucune fonction n'est appelée à l'extérieur de l'objet, les méthodes __set et __get seraient appelées, dans le cadre d'une simple assignation ou "pointage" par exemple.

Là, moi je comprends __set et __get comme étant des méthodes "par défaut" pour CREER de nouvelles variables et pas seulement leur assigner une valeur.

Je suis certainement à côté de la plaque, mais les avis divergent même sur la doc : le dernier post de la doc présente bien __set et __get comme accesseurs par défaut pour des variables existantes.


Merci pour vos réponses,

à plus,
Frédéric

[Invité]

Bonjour à vous deux,

je débute en prog, alors j'essaie de résumer ce que j'ai compris de votre discussion et de la page de manuel :

pour accéder aux variables membres d'une classe : j'ai 2 possibilités :

1. public : à "bannir" si l'on veut un contrôle à l'entrée
2. méthodes setter et getter à définir soi-même, sûr mais peu flexible

J' ai un peu de mal à comprendre le rôle des méthodes __set et __get. Je comprendrais si elle jouait le rôle d'accesseurs par défaut : on définirait un setter et un getter pour chaque membre et au cas où aucune fonction n'est appelée à l'extérieur de l'objet, les méthodes __set et __get seraient appelées, dans le cadre d'une simple assignation ou "pointage" par exemple.

Là, moi je comprends __set et __get comme étant des méthodes "par défaut" pour CREER de nouvelles variables et pas seulement leur assigner une valeur.

Je suis certainement à côté de la plaque, mais les avis divergent même sur la doc : le dernier post de la doc présente bien __set et __get comme accesseurs par défaut pour des variables existantes.


Merci pour vos réponses,

à plus,
Frédéric

Bonjour,

Les avis divergent sur l'utilisation de __set() et __get(), mais la documention officielle de PHP ainsi que ses développeurs fait foi, et ces méthodes ne sont aucunement destinées à remplacer des accesseurs.

Le fait de pouvoir les utiliser pour "créer" (affecter) des variables ou obtenir leur valeur est une aberration du langage, ce n'est pas prévu pour, dans certains cas cela ne marche pas, et il est fort possible que cela ne marche bientôt plus !

La surcharge définit plusieurs implémentions d'une même méthode ou attribut, leurs comportements sont différenciés par leur contexte d'éxécution (La classe utilisée).

Pour finir à ce sujet, définir soi-même ces méthodes set et get, ce n'est pas plus sûr (tout ce qui est sûr c'est que marchera partout), et contrairement à ce que tu penses, ce sera justement plus flexible !

Concernant les visibilités :

Première chose : la visibilité n'a rien avoir avec la sécurité telle que tu la conçois. Elle ne protège pas des saisies utilisateur, mais plutôt de celle des programmeurs.

Donc, le fait de ne pas utiliser d'attribut "public" ne te protégera pas des entrées utilisateur (le contrôle des saisies doit se faire de toute façon à un niveau ou l'autre que ce soit des variables membres "public" ou non).

Privilégier les attributs private et protected fait parti des conventions de codage orienté objet, ce fondamental s'appelle d'ailleurs "l'encapsulation".

En bref, ce principe consiste à conserver l'intégrité d'un objet en ne permettant pas que ces attributs soient modifiés n'importe ou et n'importe comment par le ou les programmeurs.

La visibilité private confine tous les attributs (ou méthode) à la classe qui les a déclaré.

La visibilité protected permet de confiner les attributs (ou méthodes) à la classe qui les a déclaré ainsi qu'à toute celles qui l'étendent.

Par ailleurs, ce principe te permet d'assurer facilité de gestion, lisibilité et robustesse à ton code source.

Bye

[fredrik]

Salut,

merci pour tes réponses. Elles m'ont aidé à comprendre que j'avais compris pour le coup des modificateurs d'accès (qu'ils sont destinés à obliger les contrôles pour une classe appelante) J'inclus systématiquement au moins un contrôle de type dans mes setters.

Je mets donc résolu.

A plus,

Frédéric