Mouais... Il n'empêche qu'avec ce système, le couplage entre les morceaux de code est hyper fort...
Admettons, si je veux changer le nom de mon attribut "message" en "messages", il va falloir se taper tout le code pour trouver les "$login->message" et les remplacer? Alors, ok, on va me répondre "OSEF, y'a le refactoring". Mais donc, impossible de publier le soft en Open Source, car l'option de refactoring de ton éditeur ne va pas toucher les codes des autres utilisateurs (qui devront donc faire le refactoring eux-mêmes, donc, y'a duplication d'opérations entre les différents projets).
Ou alors, il faut une forme de "redirection" dans ton getter magique, qui renverrait les appels à $login->message vers $login->messages... En ce cas, on se retrouve avec des pépins qui trainent de ci de là dans le code, et qui non seulement le rendent dégueulasse, mais également le ralentissent, et surtout, finiront par le rendre impossible à maintenir dans l'avenir...
Quand à "l'underscore ca prévient le développeur", c'est une solution de forme, pas de fond... C'est aussi pertinent que de créer des variables avec un nom en majuscules, et de dire "c'est des majuscules, donc, c'est une constante"... Soit le développeur, soit le "hacker" pourra changer ces règles sans soucis. Et aussi, tu comptes faire 60 pages de spécifications pour dire "majuscules = constante, underscore = read only, deux underscore = write only, underscore et majuscules = read only et constante, underscore puis P puis underscore, puis K = paramètre kernel"...
C'est pas franchement propre je trouve, et le loose coupling, tu peux le mettre aux toilettes et tirer la chasse !
Je ne trouve pas l'argument du "tu fous un underscore" viable, c'est un peu comme dire "tu fous ton HTML dans un tableau et voilà, t'as ta présentation" ou "tu ajoute un GIF transparent et c'est réglé pour le positionnement"... Ca, y'a 10 ans, on trouvait que c'était bien, et maintenant, on a compris que c'était totalement dégueulasse.
Admettons, si je veux changer le nom de mon attribut "message" en "messages", il va falloir se taper tout le code pour trouver les "$login->message" et les remplacer? Alors, ok, on va me répondre "OSEF, y'a le refactoring". Mais donc, impossible de publier le soft en Open Source, car l'option de refactoring de ton éditeur ne va pas toucher les codes des autres utilisateurs (qui devront donc faire le refactoring eux-mêmes, donc, y'a duplication d'opérations entre les différents projets).
Ou alors, il faut une forme de "redirection" dans ton getter magique, qui renverrait les appels à $login->message vers $login->messages... En ce cas, on se retrouve avec des pépins qui trainent de ci de là dans le code, et qui non seulement le rendent dégueulasse, mais également le ralentissent, et surtout, finiront par le rendre impossible à maintenir dans l'avenir...
Quand à "l'underscore ca prévient le développeur", c'est une solution de forme, pas de fond... C'est aussi pertinent que de créer des variables avec un nom en majuscules, et de dire "c'est des majuscules, donc, c'est une constante"... Soit le développeur, soit le "hacker" pourra changer ces règles sans soucis. Et aussi, tu comptes faire 60 pages de spécifications pour dire "majuscules = constante, underscore = read only, deux underscore = write only, underscore et majuscules = read only et constante, underscore puis P puis underscore, puis K = paramètre kernel"...
C'est pas franchement propre je trouve, et le loose coupling, tu peux le mettre aux toilettes et tirer la chasse !
Je ne trouve pas l'argument du "tu fous un underscore" viable, c'est un peu comme dire "tu fous ton HTML dans un tableau et voilà, t'as ta présentation" ou "tu ajoute un GIF transparent et c'est réglé pour le positionnement"... Ca, y'a 10 ans, on trouvait que c'était bien, et maintenant, on a compris que c'était totalement dégueulasse.