Reprise du message précédent :

class A{
  private $toto;
 
  function getToto(){
     return $this->toto
  }
}
 
class B{
 
 function __construct(){
   $this->toto = 'foo';
 }
}
 
$bar = new B;
 
echo $bar->getToto(); // NULL

private ça pue du cul

+1 jamais vu l'intérêt quel que soit le langage

 
Question d'habitude...et ce con de langage devrait prévenir au lieu de faire n'importe-quoi, putain...

Il arrive que tu ne veuilles pas qu'une classe fille puisse toucher à une variable membre...
Si tu commences à raisonner comme ça tu finis par penser que c'est aussi bien de tout mettre en public...

t'as un exemple la comme ça ?

 
Autant que tu veux...pour moi la bonne réponse à mon problème n'est pas de passer $toto en protected, hein.
$toto appartient à la classe A. Si à un instant toto devient une valeur calculée ça n'a pas à impacter la classe B.
La solution est donc d'implémenter setToto() dans la classe A, et de l'utiliser dans la classe B au lieu d'essayer d'attaquer directement la variable.
D'ailleurs il ne faudrait pas toucher à $toto dans la classe A en dehors des getter et setter non plus, hein...

Oui Ou tout en protected, comme en ruby

J'ai pas dit ça

Ouais, valable si il y a bien les getters et setters correspondants.
 
Mais si c'est pas le cas ça peut être ultra relou parce que ça limite grave les surcharges possibles.

Tout en private§§§

 
Une variable ne devant pas être utilisée autrement que via les getter/setter ce problème n'existe pas.

Fais péter ton usine à gaz

Une classe c'est une boîte noire donc à l'intérieur on y fait ce qu'on veut, donc au plus simple

 
Si tu permets un accès direct aux variables tu fais des trous dans la boite noire.

Sauf que tu te retrouves à créer des getter/setter potentiellement protected pour toutes les variables internes de ton objet, au cas où une classe enfant en ait besoin

 
Bah après ça dépend de ce que tu veux pouvoir faire de ta classe, hein...mais perso protected sur des variables je trouve pas de cas d'utilisation justifié...soit tu peux vouloir y accéder dans une classe fille et il faut alors passer par des getter/setter pour éviter de tout péter au moindre refactoring de la classe mère, soit tu en as pas besoin et dans ce cas private est parfait...

Accès direct de l'intérieur seulement pour moi une classe fille et une classe parente c'est la même boîte noire.

 
Même combat, si ta variable devient calculée tu l'as dans le cul à devoir revoir tout le code de ta classe pour vérifier les accès directs...alors qu'avec des méthodes d'accès tu n'as que celles-là à revoir et c'est réglé.
 

 
wait, wat?
 
tu bosses sous symfony, non?
Il se passerait quoi si tu avais accès direct aux variables d'une des classes du framework que tu étends, et que lors d'une mise à jour elle a disparu? ça casse ton code et tant pis?
C'est à l'équipe qui dev symfony de recoder tes classes, aussi?

(mais sinon oui j'ai tendance à me faire chier à coder des getter/setters sans intérêt...je prie pour l'apparition prochaine d'un wizard d'ajout de variable membre dans les IDE php )

ça m'obligerait à faire hériter toutes mes classes de ce machin, c'est un poil pénible...l'idée ce serait que php fasse ça tout seul (quitte à ajouter un switch dans le php.ini ou je ne sais quoi), mais oui.

C'est le cas et c'est parfait pour surcharger les comportements à volonté.

Perso j'ai jamais eu de pb alors que je surcharge tout et que j'ai passé 3 versions majeures. Ils doivent faire gaffe je suppose (justement pour les protected ?).

 
Bah pour moi c'est des mauvaises pratiques.
Remarque grâce à la magie de php ils peuvent toujours faire disparaitre la variable mais récupérer le truc à coups de __get et __set...

Relis la conversation, skeye est de ton côté

 
Relis-moi, ce que je trouve dégueu c'est de distribuer du code destiné à être étendu (genre un framework), en laissant des accès directs aux variables internes au lieu de getter/setter.
 
 
Le n'était pas particulièrement pour __get et __set cette fois, mais plutôt pour l'utilisation possible que je suggérais.
Ne pas mettre de getter/setter explicites, et si la variable doit être enlevée rattraper le coup justement via des accesseurs génériques c'est particulièrement paradoxal, et moche...non?

Fin bon je vois mieux l'utilité de private du coup, à petite dose ça peut être pratique ouais.

Merci bonsoir

Après, je vais ptet dire une connerie, mais à l'échelle d'un framework entier faire ça tout le temps ça peut jouer sur les perfs non ?

 
Tu préfères quoi, des perfs OK et un framework dont les mises à jour risquent de faire exploser la moitié des applis qui s'appuient dessus, ou un framework moins performant avec des mises à jour faciles?

Solution 3, un framework performant, flexible, mais dont les devs sont un peu plus limités par la compatibilité.

Pour ça il faut un truc très bien documenté, et une très grande rigueur du coté des devs du framework.
Disons qu'au lieu de forcer le framework à rester compatible avec les applis qui l'utilisent, tu demandes aux développeurs de faire en sorte que ce soit le cas...c'est un risque à évaluer.

 
Y'a pas de bonne réponse universelle.
Quand tu sais pertinemment comment va se comporter ta variable, tu t'emmerdes pas avec une paire inutile de getter/setters sur un truc protected.

Pas plus qu'avec des setters  

Bof, "tout ce qui est protected ne doit pas bouger" et hop.

tant que je n'utilisais pas symfony, l'id de mes objet était en private avec un get défini explicitement. hors de question de permettre la modification de l 'exterieur

le reste était en protected + une fonction__call des familles qui va bien

hep les gars, j'ai un file_exists() qui renvoie false, mais le fichier existe bien, et sqlite arrive bien à écrire dedans.

sur le réseau?

non, dans c:\windows\temp\test.db

ça ne se produit que sur une seule machine, toutes les autres ça marche.

L'utilisateur qui exécute apache n'a pas les droits de lecture sur le répertoire?

c'est IIS (PHP fastCGI) et sqlite (par PDO par doctrine) arrive à créer le fichier dedans (et on parle de windows\temp).  
C'est possible d'avoir écriture et pas lecture sous windows ?

Aucune idée, je suppose que oui...t'as testé un listage du répertoire en php pour voir?