L'Agilitateur - Mot-clé - java - CommentairesCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearLa fausse bonne idée des Virtual Extension Methods dans Java 8 - Oazurn:md5:c775eb3c860d273274c91597aef3f5ff2012-03-22T10:42:23+01:002012-03-22T10:44:22+01:00Oaz<p>J'ai trouvé ce qui correspond effectivement aux extension methods dans scala : les définitions implicites (implicit def) <a hreflang="en" href="http://hestia.typepad.com/flatlander/2009/03/scala-for-c-programmers-part-5-implicits.html" rel="ugc nofollow">http://hestia.typepad.com/flatlander/2009/03/scala-for-c-programmers-part-5-implicits.html</a></p>
<p>Scala ayant eu besoin de 2 concepts distincts ("trait" et "implicit def"), je pense que l'on peut affirmer que l'on traite de 2 choses définitivement distinctes :</p>
<ol><li>L'extension de types lors de la définition des objets (définition de classe + instanciation) dont les "traits" représentent peut-être la forme la plus avancée et les VEM une version simplifiée</li>
<li>L'extension de type lors de l'utilisation des objets pour laquelle les définition implicites offrent un mécanisme intéressant et les SEM une version simplifiée</li>
</ol>
Ceci étant dit, je reste convaincu que l'extension <ins>à l'utilisation</ins> est la bonne approche pour rajouter les filter/map/reduce car la puissance des lambdas se concrétise dans la possibilité pour un utilisateur de types externes de définir un DSL.<br />Par ailleurs, la conclusion du billet reste valable : l'extension de types lors de la définition est une fonctionnalité orientée développeur de composant/framework tandis que l'extension de type lors de l'utilisation est une fonctionnalité orientée développeur d'applications.<br />La fausse bonne idée des Virtual Extension Methods dans Java 8 - Oazurn:md5:0c73eca10d6e25e26db68390966f21032012-03-21T10:10:03+01:002012-03-21T10:10:03+01:00Oaz<p>Merci. C'est intéressant.<br />Je ne pense pas que cet exemple réponde complètement au besoin (le trait est rajouté à l'instanciation et non pas à l'usage au sens large) mais ça me donne envie de regarder Scala dans les détails.</p>La fausse bonne idée des Virtual Extension Methods dans Java 8 - Miguelurn:md5:153a1fc6aea88ddf0e43d7ef714a64692012-03-21T08:58:06+01:002012-03-21T08:58:06+01:00Miguel<p>Non, il faut distinguer typage statique d'avec extension statique. Les langages à typage statique peuvent supporter l'extension dynamique par trait. Scala, que tu cites, le supporte, dont voici un exemple de tissage dynamique :<br />
val mylist = new List[String] with Filtering</p>La fausse bonne idée des Virtual Extension Methods dans Java 8 - Oazurn:md5:b46c052806aef54f15317f4376d32b5b2012-03-20T18:15:26+01:002012-03-20T18:15:26+01:00Oaz<p>Ok.<br />Donc si on se limite aux langages à typage statique, le seul cas qui reste en course, c'est l'extension du type à sa définition.<br />C'est, je crois, la seule utilisation des traits possible en Scala (seul langage à typage statique et proposant les traits que je sois capable de citer)</p>
<p>Et c'est là que les extension methods de C# apportent quelque chose en plus : le type est étendu <ins>à l'usage</ins> mais à travers des <ins>définitions statiques</ins>.</p>
<p>Je ne veux pas éluder le cas des typages dynamiques où l'utilisation facilitée des traits résout effectivement bien des problèmes mais c'est hors-contexte par rapport au sujet du billet. Les types dynamiques viennent avec leur lot de défauts qui seraient à prendre en considération pour une comparaison équitable.</p>La fausse bonne idée des Virtual Extension Methods dans Java 8 - Miguelurn:md5:5f37d56b2562c8536df913546a4b27cc2012-03-20T17:45:10+01:002012-03-20T17:45:10+01:00Miguel<p>Par ce que dans un trait tu rassembles les propriétés transverses aux types et qu'ensuite tu étends les types de ton système (ou les objets d'un type donné) avec le trait, que ces types soient ou non externe à l'application. En fait, un trait n'est rien d'autre finalement que l'implémentation dans un langage orienté-objet des types abstraits de données communs aux langages fonctionnels typés.</p>
<p>Ceci peut se faire de plusieurs façons différentes, selon les langages qui supportent le concept de trait :<br />
- tu étends ton type à sa définition (extension statique),<br />
- tu étends ton type à son usage (extension dynamique: tous les objets profitent du comportement),<br />
- tu étends des objets d'un type donné à leur instanciation ou dynamiquement (extension dynamique: seuls certains objets en profitent: idéal pour la notion de rôle)</p>La fausse bonne idée des Virtual Extension Methods dans Java 8 - Oazurn:md5:8e026f492fc0a25386f346cd8e86586d2012-03-20T16:36:28+01:002012-03-20T17:03:01+01:00Oaz<p>Bonjour Miguel,</p>
<p>En quoi les traits (dont je ne nie pas l'apport conceptuel) permettent d'étendre le comportement d'un type externe à une application ?</p>La fausse bonne idée des Virtual Extension Methods dans Java 8 - Miguelurn:md5:a06c0c3cf57893eaac6aafb187cc01262012-03-20T15:28:34+01:002012-03-20T15:28:34+01:00Miguel<p>Je pense que les deux approches ne sont pas bonnes et ne sont que des "cuisines" techniques de ces langages.<br />
AMHA, la meilleure approche, est celui des traits, qui est un apport conceptuel et non uniquement technique. Il aura l'avantage de définir des méthodes de même catégorie (même traits) que l'on pourra tisser avec les classes d'objets.</p>