Compass : East Oriented

[srm]

Bah pourtant je te l'ai dit là et ça te semblait bon :

Donc ça t'embête de mettre à jour une interface, mais pas de mettre à jour un type de retour pour qu'il retourne une nouvelle valeur connu nul part .

Cas 1 :
Tu mets à jour ton interface pour y ajouter des trucs, quiconque l'utilisait voit directement au lancement de son programme que c'est cassé.

Cas 2 :
Tu as changé le retour de ton getter pour pouvoir retourner PotDeVin, personne le sait sans regarder l'intérieur de ton code, quelqu'un qui lance son programme et qui ne savait pas que tu avais ajouté le type de retour PotDeVin peut avoir un gros bug dans son programme.

[Xenos]

Non, ça ne me semblait pas bon, puisque dans les langages où le retour est typé, c'est pareil (changer le typage de retour cassera les autres codes) et ...

...dans le cas de PHP, j'ai deux objections:
• La prochaine version implémentera (d'après niahoo) le typage des retours, donc la compilation sera cassée
• Le langage PHP actuel part du principe que les retours sont non typés, donc si un code considère qu'un retour est toujours d'un typage donné, en PHP, c'est une erreur puisque le langage autorise n'importe quel retour. Du coup, les codes "mal faits" (qui "typent" les retours alors que le langage ne le fait pas) seront effectivement cassés. Les bons codes (qui vérifient les retours car ceux-ci sont non-typés) ne seront pas cassés: PotDeVin tombera dans les if (!is_a($retour, Papiers)) throw new \Exception(...);.

Sur du PHP, quelqu'un qui se basait sur le typage du retour ferait une erreur (puisque les retours ne sont pas typés par le langage, pour le moment).
PHP n'a en fait pas le problème que tu essaies de faire apparaitre (à savoir, que la classe appelée est forcée de retourner un type d'objet précis, les types de base était interchangeables en PHP).

Et si l'appelé s'adapte à l'interlocuteur, comment cela se passe sur une lib (un .phar, qu'on n'a pas le droit de modifier donc)?


Pour moi, le mot-clef return est juste franchement bien fichu puisqu'il se charge de tout ce bazar (passer le conteneur de résultat en paramètre à l'appelé, que l'appelé passe son résultat à ce conteneur, que ce conteneur transmette le résultat à l'appeleur, et que l'appeleur reprenne le fil de ses opérations) que tu émules dans le code au lieu de le faire dans le langage. Dans un appel de méthode/fonction, l'appeleur est toujours passé implicitement à l'appelé (d'où l'existence d'une stack trace). Lis-le comme push $result au lieu de return $result si tu veux.

[srm]

Prenons l'exemple de ce programme en Scala :

class Temperature (value: Double, unitType: String)

{

 def getValue: String = value + "°" + unitType

}



val temperature = new Temperature(27.3, "C");

val temperatureIs = temperature.getValue;

println(temperatureIs);

Je décide de changer le type de retour de getValue pour un Double :

class Temperature (value: Double, unitType: String)

{

 def getValue: Double = value

}



val temperature = new Temperature(27.3, "C");

val temperatureIs = temperature.getValue;

println(temperatureIs);

Mon programme marche toujours.
Du coup tu te dis "bah c'est super non ?"

Je continue de modifier mon code comme suivant :

class Temperature (value: Double, unitType: String)

{ 

 def getValue: Double = value

}



val temperature = new Temperature(27.3, "C");

val temperatureIs = temperature.getValue;

val newTemperature = temperatureIs + 30;

println(newTemperature);

Ca marche toujours, la vie est belle.
Puis le type de retour change de nouveau :

class Temperature (value: Double, unitType: String)

{

 def getValue: String = value + "°" + unitType

}



val temperature = new Temperature(27.3, "C");

val temperatureIs = temperature.getValue;

val newTemperature = temperatureIs + 30;

println(newTemperature);

Et là... boum : 27.3°C30
Un bug alors que je ne m'y attendais pas du tout alors que j'ai bien le type de retour précisé.

[srm]

Si une librairie ne donne pas le getMachinQueTuVeux dans un phar tu fais comment ? Tu as le même soucis

[Xenos]

Si le getMachinQueTuVeux n'existe pas, le pushDataTo non plus, je ne vois pas en quoi East améliore les choses.
D'ailleurs, si le getMachin n'existe pas, c'est que tu essaies de t'attaquer à la mécanique interne de la classe (ce qui est interdit de base en OO).

Dans ton exemple Scala, c'est là encore une mauvaise utilisation du langage (je ne le connais pas, mais il semblerait qu'ici aussi, comme en PHP, les retours ne soient pas typés par le langage): si le retour n'est pas typé par le langage, il ne faut pas s'y fier (puisque la méthode retourne ce qu'elle veut).
Par ailleurs, un bon code est fermé aux modifications: si le typage (fixé par le langage, ou par la phpdoc) de retour de la méthode te déplait, il faut créer une nouvelle méthode (et déprécier l'ancienne), et non éditer la signature publique de la méthode existante.

En fait, je trouve que tu te fies à un contrat de méthode qui serait Type methodeName(ParametersType...) alors que ton langage a un contrat de la forme mixed methodeName(ParameterType...). Mieux vaut se plier au langage (le code évoluera alors tout seul quand le langage avancera) plutôt qu'émuler des trucs dedans (ça ressemble aux émulateurs de classes en Javascript).

Note: cela m'est sorti de l'esprit, mais de toute façon, East ou West, en PHP, les erreurs ne sortiront qu'au RunTime, et non à la compilation. Seul l'IDE saura te faire de l'analyse statique (genre PHPAnalyzer) pour te dire "là, ça va foirer" (et typehinting ou phpDoc, les deux se valent dans ce cas).

[srm]

Je n'ai pas dit que East améliorait le cas pour le phar, je dis juste qu'il ne l'empire pas, c'est tout.

Oui tu ne connais pas le langage, car c'est un langage typé exactement de la même façon que le Java.
La seule différence c'est qu'il fait de l'inférence de type, ça veut dire que tu n'as pas à préciser le type partout.
def getValue: Double
Ca veut dire "type de retour Double"
def getValue: String
Ca veut dire "type de retour String"

Bah si je suis le créateur de ma librairie et que pour une raison X ou Y je veux changer le type de retour, j'ai encore le droit non ?
Il suffit que je change la version de ma librairie pour dire que c'est un changement qui casse l'API.
Et dans ce cas un dev qui utilisait ma librairie devra regarder en détail tous les changements et bien tout tester.
Avec East il n'aura pas besoin, il lancera son programme et verra tout de suite les interfaces cassées.

On ne tord pas du tout le langage en East, on fait un truc parfaitement naturel et normal.
On utilise des interfaces partout et on appel des méthodes.

[srm]

Sauf que comme je t'ai montré, en West il y a des erreurs qui ne remonteront MEME PAS au Runtime.
Et qui peuvent même passer inaperçue à la compilation d'un langage fortement typé.

[niahoo]

Mais dans le cas d'une librairie par exemple (désolé j'ai pas tout suivi), si tu as besoin d'une info depuis un objet de la librairie, tu dois modifier la libraire pour ajouter la méthode machinAskedByTruc ?

[srm]

Si la librairie veut que tu ai accès à quelque chose elle a à mis un machinAskedByTruc ou Truc est une interface qu'elle met à disposition.

[Xenos]

Alors, de la même façon, si la lib veut que t'ai accès à Machin, elle aura un getMachin.

Scala a l'air d'être un typage lâche (ou faible? je sais plus l'adjectif...) Les variables n'étant pas typées, c'est le code utilisateur qui est en charge de faire ses checks (les retours sont quelconques, car leur typage est hors contrat): (Double)temperatureIs + 30 devrait être utilisé.

D'ailleurs, l'opérateur new et l'opérateur + sont codés en West. new n'est jamais qu'un appel à la fonction New("ClassName", Parameters) et l'opérateur d'addition, un appel à ResultType operator+(LeftType, RightType); cela se voit facilement en C/C++.