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).
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).