Compass : East Oriented

[srm]

Tu le fais exprès ou quoi ? Tu fais du Java pourtant et je t'ai dit que le Scala avait exactement le même typage que Java. Donc c'est un typage fort.

Code :

scala> var age = 33;
age: Int = 33

scala> age = "Sylvain";
<console>:8: error: type mismatch;
found   : java.lang.String("Sylvain")
required: Int
       age = "Sylvain";
             ^

Tu vois bien avec cet exemple que c'est fortement typé.
Et l'inférence de type m'a permis d'écrire :
var age = 33
au lieu de :
var age: Int = 33

Et on s'en fou que l'opérateur new soit West ou East, ça n'a pas d'importance. Je vois même pas pourquoi tu en parles.
Donc tu y vois bien l'avantage de l'East vs West avec les exemples que je t'ai donné interface vs getter.

[niahoo]

Ok mais donc pour pouvoir faire

Code :

papierAskedByPolicier(Policier $policier)
papierAskedByDarling(Darling $darling)

Il faut donc avoir une interface Darling ? Je trouve qu'on finit par avoir beaucoup d'interfaces juste pour un vieux getter quand même.

[srm]

Cependant il ne faut garder à l'esprit qu'il n'y a pas généralement beaucoup d'objets de natures différentes qui communique avec un même objet commun.

De plus ça n'est pas du tout un simple getter et j'ai expliqué avant pourquoi

[Xenos]

Okay (non, je ne fais pas exprès: je ne connais juste pas Scala ).
Dans ce cas, pour moi, c'est l'inférence de typage qui est utilisée de travers (le typage étant inféré, on ne peut pas faire de temperatureIs + 30, ou alors, en effet, on prend le risque d'avoir n'importe quel typage).

Je parle des opérateurs car tous les assignements sont du West-like (c'est surtout visible en C/C++, puisque ces opérateurs peuvent se surcharger, y compris l'opérateur d'assignement = il me semble). Peut-être existe-t-il des langages pur-East, mais Scala/PHP/Java/C++ ne m'ont vraiment pas l'air d'en être.

Bon, bref, je suis peut-être borné ou autre, mais je ne vois toujours pas d'avantage à ajouter des interfaces pour chaque message (méthode) à passer à un objet, puisqu'à chaque exemple, c'est la façon d'utiliser le langage qui m'a semblé mauvaise (en PHP, pas de typage de retour, donc cela peut être n'importe quoi et on ne peut pas s'y fier, en Scala si le typage est inféré, c'est logique de ne pas savoir ce qu'on manipule et de devoir le checker, en C/C++/Java changer le typage de retour invalidera les codes utilisateurs).

A une époque où, justement, je voulais "typer" mes retours en PHP, j'avais eu l'idée de passer un paramètre supplémentaire aux méthodes, en passage par référence, pour qu'elles y mettent leur résultat (style Classe::getTemperature(Temperature& $temperature)). C'est considéré comme du East ça?

[srm]

Je te montre une solution qui marche dans TOUS Les cas.
Toi tu me parles d'une solution qui marche dans certains cas.

Et tu ne vois pas l'intérêt ?

[Xenos]

La solution West marche dans tous les cas où le langage est utilisé correctement. Après, si le langage est utilisé de travers (en considérant par exemple qu'une méthode PHP donnée renverra toujours un String, ce qui n'est pas un paradigme du langage PHP), oui, cela ne marchera pas à tous les coups... Mais la faute en revient à l'utilisation du langage, pas à West/East (ni même au langage).

East intègre le typage du retour dans les paramètres des méthodes: y'a pas grand chose à redire contre cela, ça marche, pourquoi pas, c'est un style (comme la guerre spaces vs tabs pour l'indentation), mais pas au prix d'un dénigrement du West car l'un n'est pas mieux que l'autre, faut juste connaitre son langage.

[srm]

N'importe quoi...
J'ai utilisé le Scala correctement.
Le PHP aussi et en PHP7 il aura le même soucis que j'ai soulevé avec le Scala et l'inférence de type.

[Xenos]

Non, pour moi, PHP n'est pas utilisé correctement si le codeur considère que telle méthode doit retourner tel type de donnée (ce n'est pas un paradigme du langage).
Pour l'inférence de Scala (j'en connais peu, mais bon je vais quand même la ramener :p ), c'est pareil: le retour des méthodes est peut-être typé, mais l'inférence implique qu'on manipule une variable dont on ne connait pas le typage réel, donc les appels à des méthodes / opérateurs (comme +) seront indéterminés à la "compilation".

[Xenos]

Question pour du PHP-East: si je reprends le thermomètre, se coderait-il bien comme ceci:

interface IThermometre {

    public pushTemperature(ITemperatureReceiver $receiver);

}

interface ITemperatureReceiver {

    public thereIsATemperature($temperature);

}

interface ITemperature {

}

class Thermometre implements IThermometre {

    public pushTemperature(ITemperatureReceiver $receiver) {

        $receiver->thereIsATemperature($this->temperature);

    }

}

Mais le défaut de typage se reporte sur thereIsATemperature($temperature), auquel on peut passer ce qu'on veut (int, string, ou objet).
J'ai essayé en passant par un bean Temperature, mais soit on se retrouve avec le même problème (on passe un "mixed" au constructeur de Temperature), soit on modifie les attributs publics de Temperature.

J'ai raté quelle marche? Temperature ou thereIsATemperature() doivent elles-mêmes vérifier les typages de leurs paramètres d'entrée ?

[srm]

J'ai rien compris à ton explication.

Pour le code PHP :

interface TemperatureReceiver {

    public thereIsATemperature(TemperatureValue $temperatureValue);

}

Tu dois utiliser un valueobject