Comme tout le monde, j'ai des propriétés que je souhaite rendre inaccessible, d'autres en lecture seule, d'autres en écriture et lecture. (système getter setter)

Il y a t-il des conventions d'écriture ?

de type :

private $_mavar; // Ce sera inaccessible
private $mavar2; // Ce sera en lecture seule
public $mavar3; // Ce sera en lecture/ecriture

avec

__get ($mavar) {

if (substr($mavar,0,1) == "_") throw new Exception ("Private var");
return $this->$mavar;

}

Ou tout mettre en private avec $__var pour inaccessible, $_var pour lecture seule et $var lecture et écriture, avec un getteur (__get) et setteur (__set) ?

Ca m'éviterait de gérer une liste d'exception ... car actuellement j'ai un objet BattonGraph qui possède une variable Property(array) en private, dont on peut définir chacune des propriétés avec la méthode setProperty(); C'était aussi un moyen de regrouper tout pour l'utilisateur. Mais là ... je me dis que ce serait plus simple et plus propre de changer les propriétés directement de cette façon $mavar->property

Actuellement dans setProperty je teste que le typage des deux versions de var (l'ancienne et la nouvelle) sont pareils, pour ainsi faire un typage plus fort.

C'est à voir donc ...

Personnellement, j'utilise un autre système, un peu de code sera plus explicite :

<?php
class maclasse
{
    const ACCES_PRIVE = "Accès en %s à la propriété privée %s interdit";
    private $_mavar; // Ce sera inaccessible
    private $mavar2; // Ce sera en lecture seule
    private $mavar3; // Ce sera en lecture/ecriture
    

    /**
     * Getter magique
     * 
     * Retourne la valeur de la propriété uniquement si elle
     * est mentionnée dans les accès autorisés en lecture
     */
    public function __get($mavar)
    {
        $aLecture = array('mavar2', 'mavar3');
        if (in_array ($mavar, $aLecture))
        {
            return ($this->{$mavar});
        }
        else
        {
            $erreur = sprintf (self::ACCES_PRIVE, 'lecture', $mavar);
            throw new Exception ($erreur, E_USER_WARNING);
        }
    }
    
    /**
     * Setter magique
     * 
     * Affecte la valeur à la propriété uniquement si elle
     * est mentionnée dans les accès autorisés en écriture
     */
    public function __set($mavar, $valeur)
    {
        $aEcriture = array('mavar3');
        if (in_array ($mavar, $aEcriture))
        {
            $this->{$mavar} = $valeur;
        }
        else
        {
            $erreur = sprintf (self::ACCES_PRIVE, 'écriture', $mavar);
            throw new Exception ($erreur, E_USER_WARNING);
        }
    }
}

J'utilise des tableaux dans lesquels je liste les propriétés auxquelles je permets un accès.
Pour la lecture seule, ça concerne __get(), pour l'écriture, la méthode __set() : celles qui peuvent être lues et modifiées se retrouveront dans les deux tableaux.

Ceci dit, tout ceci n'a rien a voir avec le typage des données : quand on parle de typage, on parle de chaines de caractères, de tableaux, d'entiers, d'objets, etc... et c'est totalement indépendant de leur visibilité.

Oui merci de ta réponse, j'avais déjà pris une décision
Ainsi, seules les variables commençant par __ sont réellement privée ou protégée (traduction littérale) en lecture. Et seules les variables commençant par _ sont protégées en écriture et lecture. Les autres sont publiques. Mais c'est là que mon problème apparaissait réellement. Car j'aurai pu faire mes publiques "public". Mais je veux forcer un type, je veux en quelque sorte essayer de rendre PHP fortement typé (lol je rêve). Donc je déclare par exemple $mavar = 1; Lorsque l'utilisateur voudra changer la variable, php comparera les deux types et lancera une exception si ce n'est pas les mêmes. C'est un peu tiré par les cheveux mais bon ...

Par contre, je ne sais toujours pas comme dire à une constante d'être un objet ... ni à une variable statique d'être un objet sans intervention externe.

Autre problème :

const BLOCKS_FILLED = 1;
const BLOCKS_BORDER = 2;
const BLOCKS_ALL = 3;

l'utilisateur tape par exemple $monInstance->blocksType(Graph::BLOCKS_FILLED); Je ne peux pas l'empêcher de mettre "1" à la place. Ce n'est pas grave, puisqu'ils ont la même valeur.
Mais j'aurais voulu qu'il ne puisse pas mettre autre chose que les valeurs de constantes. En quelque sorte, définir une plage ... Et là
Ca m'oblige actuellement à vérifier que blocksType est bien 1,2 ou 3 (en fait je tape self::BLOCKS_FILLED, ... donc encore plus long )

j'ai jamais eu ce soucis moi, c'est par flemme de faire des getVariable et setVariable ?

Soucis pour les variables ?

Oui car passer par setPropriété, c'est passer (pour l'utilisateur), par une méthode et non par la propriété, pareil pour getPropriete, c'est très long pour des dizaines de propriétés (comme dans mon cas), et en plus ... oui je suis un grand flemmard. J'ai pas envie de m'amuser à taper éternellement if (is_int($var)) dans chaque setPropriété ... je préfère le faire qu'une fois, et au lieu de "int var" ou de "var:int" (as3), je fais $var = 0 et Hop, dans mon setter, il sait que j'attends un integer. Et c'est valable pour tout. D'ailleurs ça me fait penser à un beug ... si j'oublie de lui mettre une valeur il risque de tout interdire ^^. En tout cas, ça m'évite de me retrouver avec des chaines de caractères là où j'attends un nombre, et c'est une vérification et un risque en moins. Par contre, je dois contrôler en plus, et là, pas le choix (sauf en AS3, avec uint pour > 0 héhé) le contenu (par exemple, vérifier que le nombre est > 0 ou qu'il est inclu entre 0 et 3 ou qu'il est égale à une des constantes de la classe, etc.

...ca éloigne de l'esprit JAVA et C#...

Dans un sens, ça tombe bien, ici on fait du PHP

Oops je viens de retirer JAVA de JAVA - C#. C# utilise des getters et setters en passant par la propriété (pour lire ou écrire sur le "champs"), mais JAVA apparemment, n'a rien de spécial. Il faut donc créer des getMachin etc. Par contre, le typage est plus facile, ainsi un setteur tient sur une expression de code. Alors que là il faudrait lui dire (is_int($var)) ? $this->machin = $var : throw new Exception ("pov type !");

Bref, c'est vrai qu'au final, c'est pas forcément différent Je trouve en tout cas que définir un getter et setter principal est plutot pas mal et allège le code, en plus du type.

Ce que j'apprécie vraiment dans ça, mais j'aime savoir tout ce qu'il y a autour, d'où la discution, c'est que c'est un codage réduit (deux méthodes, contre 40 pour 20 propriétés lecture-ecriture, qui dit mieux ?), tout en passant "directement" par les propriétés (en apparence pour l'utilisateur de la classe), tout en controlant le type, ...

De toutes façons, le seul argument qui m'a poussé à ne pas utiliser "public" pour ces propriétés, c'est le typage ...

Je me demande si ce que j'ai écrit plus haut a correctement été lu : il n'existe aucun lien direct entre la visibilité d'une propriété et son type. Je peux avoir des entiers privés, des tableaux public, des objets protégés et que sais-je encore dans toutes les variantes de combinaisons possibles : il n'y a pas de lien de cause à effet.

Quant au getter/setter, ce sont des méthodes qui nativement ne gèrent pas les types. Vous pouvez bien utiliser des astuces, mais encore faut-il qu'elles soit valables pour valider les types de données que vous envoyez. Or le fait qu'une propriété soit privée, publique ou protégée n'interdira pas qu'elle soit initialisée avec un type de données inapproprié si aucun test n'est fait avec les fonctions natives prévues pour ça.

Enfin, je rappelle que le PHP est un langage très faiblement typé. Ça offre une certaine souplesse même si ça demande en contre-partie un peu de rigueur.

Je crois que je vais utiliser les getters setters en méthodes. Si ... j'ai bien compris, je ne suis pas vraiment novice en programmation, mais assez en programmation de groupe et conventionnelle. Ma méthode (ma ?) répond à toutes mes attentes, sauf à celle du contrôle de données. Et là, c'est finalement très embetant. En plus, elle se base d'un point de vue typage, à une valeur antérieure, ce n'est pas le top.

Au final, je pense que le setter devrait ressembler à ça

public function setBlocksWidth ($value) {
if (!is_int($value)) throw new ...
if ($value < 0) throw new ...
$this->blockWidth = $value;
}

On pourrait pousser plus loin, par exemple si on crée une classe d'envoi d'email.

ClassMail.setMailTo ("[email protected]"); // Coté utilisateur
ClassMail.setMailTo ("machin"); // Coté utilisateur
ClassMail.setMailTo (2); // Coté utilisateur

class (...)

public function setMailTo ($value) {

if (!is_string($value)) throw ...
if (!preg_match("/(mail)/",$value)) throw ...
$this->mailTo = $value;

}

et imaginer pour une programmation avancée un simple

public function setMailTo (Mail $value) {

// Mail is class Mail comme le type Url pour AS3, on peut écrire aussi : if (!$value instanceof Mail) throw ...
$this->mailTo = $value;

}

On sera alors certain (non ?) lors de l'envoi d'email que $mailTo sera correct ... après avoir vérifié qu'il a bien une valeur

Cela me permettra ainsi aussi de vérifier que la valeur donnée correspont bien à une liste de constante de class comme BLOCKS_FULL, BLOCKS_BORDER, etc

Une critique ?

PS : Je n'aime pas trop C# pour son côté Microsoft, mais il faut bien lui accorder que les getters et setters en tant que propriété et non pas méthodes, c'est quand même top ... et les indexeurs aussi (JAVA fait aussi je crois)

LOL ! Le même sujet quasiment ... http://stackoverflow.com/questions/8750 ... rs-in-java

La personne se pose au final à peu près la même question ...

D'ailleurs, je suis peut-être un peu bête ... je pourrais très bien définir des setMachin et getMachin partout et utiliser __get et __set pour rediriger automatiquement vers le bon setter ...

Du genre

public function __get ($var) {
if (methods_exists(array($this,'get' . ucfirst($var)))) return $this->('get' . ucfirst($var))(); // Attention, j'écris ça comme ça, c'est assez spéciale, il faudra peut-être passer par une fonction d'appel de méthode genre call_user_fnct ...
throw new Exception (...); // Si la méthode n'existe pas : t'as pas le droit d'écrire dessuss !!!
}

Mouais, sauf que tu n'es pas en Java mais en PHP. Faire un truc comme ceci :

public function setMailTo (Mail $value) 
{
    // Mail is class Mail comme le type Url pour AS3, on peut écrire aussi : if (!$value instanceof Mail) throw ...
    $this->mailTo = $value;
}

En PHP, ça sous-entend que ton paramètre doit être un objet de type Mail correspondant à une classe du même nom, et non une chaine.

J'ai l'impression que tu voudrais t'affranchir de quelques lignes de validation mais je crains fort que tu n'ailles au devant de déconvenues sur ce point. Mais ça ne signifie pas pour autant que tu doives écrire des millions de lignes de code : si tu reprends l'exemple que j'ai cité dans ma première réponse sur ce sujet, tu peux observer que j'utilise un tableau dans mon getter magique et un autre dans mon setter magique. L'idée qui pourrait être développée serait d'utiliser un tableau à deux dimensions qui te permettrait de stocker les types en premier niveau et les propriétés en second niveau selon le type. Et dans ce cas, tu rajoutes la validation du type de données à partir de l'index correspondant: Et là mon getter ne change pas, mais mon setter magique si, et la classe exemple de début deviendrait :

<?php
class maclasse
{
    const ACCES_PRIVE   = "Accès en %s à la propriété privée %s interdit";
    const TYPE_INVALIDE = "La propriété %s doit être de type %s, la valeur reçue est invalide";
    /**
     * @var String
     */
    private $mavar1;
    /**
     * @var Boolean
     */
    private $mavar2;
    /**
     * @var Int
     */
    private $mavar3;

    /**
     * Getter magique
     *
     * Retourne la valeur de la propriété uniquement si elle
     * est mentionnée dans les accès autorisés en lecture
     */
    public function __get($mavar)
    {
        $aLecture = array('mavar2', 'mavar3');
        if (in_array ($mavar, $aLecture))
        {
            return ($this->{$mavar});
        }
        else
        {
            $erreur = sprintf (self::ACCES_PRIVE, 'lecture', $mavar);
            throw new Exception ($erreur, E_USER_WARNING);
        }
    }
   
    /**
     * Setter magique
     *
     * Affecte la valeur à la propriété uniquement si elle
     * est mentionnée dans les accès autorisés en écriture
     * et que le type de valeur envoyé correspond au type attendu
     */
    public function __set($mavar, $valeur)
    {
        $aEcriture = array(
            'bool' => array('mavar2'),
            'int' => array('mavar3')
        );
        if (in_array ($mavar, $aEcriture['bool']))
        {
            if(is_bool($valeur))
            {
                $this->{$mavar} = $valeur;
            }
            else
            {
                $erreur = sprintf (self::TYPE_INVALIDE, $mavar, 'booléen');
                throw new Exception ($erreur, E_USER_WARNING);
            }
        }
        elseif (in_array ($mavar, $aEcriture['int']))
        {
            if(is_int($valeur))
            {
                $this->{$mavar} = $valeur;
            }
            else
            {
                $erreur = sprintf (self::TYPE_INVALIDE, $mavar, 'entier');
                throw new Exception ($erreur, E_USER_WARNING);
            }
        }
        else
        {
            $erreur = sprintf (self::ACCES_PRIVE, 'écriture', $mavar);
            throw new Exception ($erreur, E_USER_WARNING);
        }
    }
}

TU peux faire des variantes mais tu n'échapperas pas à la nécessité de valider les valeurs.

je m'embête pas moi, pas besoin de bidouille

class maclasse
{
    private $mavar1;   //public 
    private $mavar2;   //readonly
    private $mavar3;   //private

    public function setMavar1($value)
    {
        $this->mavar1 = $value;
    }

    public function getMavar1()
    {
        return $this->mavar1;
    }

    public function getMavar2()
    {
        return $this->mavar1;
    }
}  

de tout façon même si on a 15 valeurs (et c'est rare) c'est que du copier coller et c'est plus claire, surtout niveau doc

La validation de mes données c'est ce qui me pousse à améliorer mon système actuel (enfin d'hier et d'avant hier). la fonction setMailTo s'occupe justement d'être un setteur, un validateur de type et un validateur de données. Ca peut paraitre beaucoup, mais au moins, la classe définit des règles précises à l'utilisateur, et quand elle utilise une propriété, elle est sûre qu'elle peut lui faire confiance (un is_null ou isset avant parait cependant nécessaire).

Pour revenir à Mail, il s'agit d'une classe crée auparavant avec ses vérifications (comme ma classe ColorGraph). Lorsque l'on utilise Mail (avec __tostring par exemple donc directement en tant que chaine, ou en réservant un getter de contenu de type $instanceMail->mail en lecture seule), on est sûr qu'il s'agisse bien d'une adresse e-mail "valide". Tout comme ma classe ColorGraph renvoit un objet ColorGraph, que l'on appelle ColorGraph::rgb(int r > 0 && < 256, int v > 0 && < 256, int b > 0 && < 256) ou ColorGraph::hex (string code); Ainsi ma classe BattonGraph peut tranquillement utiliser quelque instance ColorGraph que ce soit : elle sera toujours valide.

Ca part un peu du principe que, quand ça m'arrange, tout est objet.

Pour ColorGraph, on peut accéder aux canaux RVB avec $monColorGraph->red, ... en lecture seulement. Ca lui assure une intégrité parfaite. Seul hic par contre c'est que $x instanceof $y est très laxiste, et autorise tous les parents de $y ... get_class() répond certainement à cette problématique.

tu sais que pour vérifier les mail t'as filter_var avec FILTER_VALIDATE_EMAIL, la plupart des regexp qu'on trouve sont faux

je m'embête pas moi, pas besoin de bidouille

class maclasse
{
    private $mavar1;   //public 
    private $mavar2;   //readonly
    private $mavar3;   //private

    public function setMavar1($value)
    {
        $this->mavar1 = $value;
    }

    public function getMavar1()
    {
        return $this->mavar1;
    }

    public function getMavar2()
    {
        return $this->mavar1;
    }
}  

de tout façon même si on a 15 valeurs (et c'est rare) c'est que du copier coller et c'est plus claire, surtout niveau doc

Oui, au final, je m'étais trop basé sur C#. JAVA le fait, alors ... Le rajout d'appel Dynamique par __get et __set se serait un gadget. Je pense le mettre (Mes classes Graph sont des bacs à sable. J'essaie de faire un super code avec, et ils représentent des graphiques. Nul besoin de dire qu'il existe déjà d'excellentes bibliothèques pour ça ... mais c'est un très bon excercice).