<?xml version="1.0" encoding="UTF-8"?><rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:media="http://search.yahoo.com/mrss/"
> <channel><title>Commentaires sur : Revue de Presse Xebia</title> <atom:link href="http://blog.xebia.fr/2009/11/30/revue-de-presse-xebia-136/feed/" rel="self" type="application/rss+xml" /><link>http://blog.xebia.fr/2009/11/30/revue-de-presse-xebia-136/</link> <description>J2EE, Agilité et SOA</description> <lastBuildDate>Fri, 10 Feb 2012 09:50:25 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=</generator> <item><title>Par : Dominique De Vito</title><link>http://blog.xebia.fr/2009/11/30/revue-de-presse-xebia-136/#comment-17854</link> <dc:creator>Dominique De Vito</dc:creator> <pubDate>Fri, 04 Dec 2009 12:27:05 +0000</pubDate> <guid
isPermaLink="false">http://blog.xebia.fr/?p=3455#comment-17854</guid> <description>Perso, ce que j&#039;aimerais, c&#039;est un auto-boxing des méthodes en objets implémentant une interface, comme je l&#039;indique ici : http://www.jroller.com/dmdevito/entry/next_jdk_wishlist_3_a
Cela couterait pas cher et cela permettrait d&#039;améliorer un peu les choses.
En gros, si j&#039;ai une méthode :
Object myProcessing(Object e) {
...
}
Méthode dont la signature est compatible avec l&#039;interface :
public interface UnaryOperator {
Object eval(Object arg);
}
avec, par ex, l&#039;utilisation suivante de cette interface :
public class AbstractList ... {
public void map(UnaryOperator op) {
...
}
}
Alors j&#039;aimerais pouvoir simplement écrire :
mylist.map(myProcessing);
Avec auto-boxing automatique de &quot;myProcessing&quot; en un objet implémentant l&#039;interface UnaryOperator.
Ce serait un plus, et une avancée qui pourrait obtenir un consensus plus facilement que les différentes propositions des closures.</description> <content:encoded><![CDATA[<p>Perso, ce que j&#8217;aimerais, c&#8217;est un auto-boxing des méthodes en objets implémentant une interface, comme je l&#8217;indique ici : <a
href="http://www.jroller.com/dmdevito/entry/next_jdk_wishlist_3_a" rel="nofollow">http://www.jroller.com/dmdevito/entry/next_jdk_wishlist_3_a</a></p><p>Cela couterait pas cher et cela permettrait d&#8217;améliorer un peu les choses.</p><p>En gros, si j&#8217;ai une méthode :</p><p>Object myProcessing(Object e) {<br
/> &#8230;<br
/> }</p><p>Méthode dont la signature est compatible avec l&#8217;interface :</p><p>public interface UnaryOperator {<br
/> Object eval(Object arg);<br
/> }</p><p>avec, par ex, l&#8217;utilisation suivante de cette interface :</p><p>public class AbstractList &#8230; {</p><p> public void map(UnaryOperator op) {<br
/> &#8230;<br
/> }<br
/> }</p><p>Alors j&#8217;aimerais pouvoir simplement écrire :</p><p>mylist.map(myProcessing);</p><p>Avec auto-boxing automatique de &laquo;&nbsp;myProcessing&nbsp;&raquo; en un objet implémentant l&#8217;interface UnaryOperator.</p><p>Ce serait un plus, et une avancée qui pourrait obtenir un consensus plus facilement que les différentes propositions des closures.</p> ]]></content:encoded> </item> <item><title>Par : Francois Marot</title><link>http://blog.xebia.fr/2009/11/30/revue-de-presse-xebia-136/#comment-17647</link> <dc:creator>Francois Marot</dc:creator> <pubDate>Tue, 01 Dec 2009 11:38:39 +0000</pubDate> <guid
isPermaLink="false">http://blog.xebia.fr/?p=3455#comment-17647</guid> <description>@Herve bonne question ! ;)
Mais les 2 ne sont pas identiques. Pour ma part j&#039;ai testé Groovy et quasiment pas Scala. Ce que j&#039;apprécie dans Groovy c&#039;est qu&#039;on peut s&#039;y mettre tout doucement. Du Groovy, c&#039;est (presque) du Java: on peut se contenter d&#039;apprendre petit à petit, c&#039;est assez sécurisant, tout en restant tres puissant. Et je pense que pour des équipes de dev déjà formées à Java, Groovy est une évolution logique. Scala par contre change beaucoup de choses. C&#039;est un autre paradigme, sans doutes tout aussi puissant, tres intéressant aussi, mais tres different ! Donc à mon avis, il sera plus dur pour des équipes entiere de &quot;faire du Scala&quot; convenablement avant un bon bout de temps: il faudra que les équipes de dev&#039; réapprennent toutes les bonnes pratiques (avec les erreurs de débutant qui en découlent).</description> <content:encoded><![CDATA[<p>@Herve bonne question ! <img
src='http://blog.xebia.fr/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /><br
/> Mais les 2 ne sont pas identiques. Pour ma part j&#8217;ai testé Groovy et quasiment pas Scala. Ce que j&#8217;apprécie dans Groovy c&#8217;est qu&#8217;on peut s&#8217;y mettre tout doucement. Du Groovy, c&#8217;est (presque) du Java: on peut se contenter d&#8217;apprendre petit à petit, c&#8217;est assez sécurisant, tout en restant tres puissant. Et je pense que pour des équipes de dev déjà formées à Java, Groovy est une évolution logique. Scala par contre change beaucoup de choses. C&#8217;est un autre paradigme, sans doutes tout aussi puissant, tres intéressant aussi, mais tres different ! Donc à mon avis, il sera plus dur pour des équipes entiere de &laquo;&nbsp;faire du Scala&nbsp;&raquo; convenablement avant un bon bout de temps: il faudra que les équipes de dev&#8217; réapprennent toutes les bonnes pratiques (avec les erreurs de débutant qui en découlent).</p> ]]></content:encoded> </item> <item><title>Par : Hervé A.</title><link>http://blog.xebia.fr/2009/11/30/revue-de-presse-xebia-136/#comment-17643</link> <dc:creator>Hervé A.</dc:creator> <pubDate>Tue, 01 Dec 2009 08:44:28 +0000</pubDate> <guid
isPermaLink="false">http://blog.xebia.fr/?p=3455#comment-17643</guid> <description>&#039;Omniprésence de Scala&quot;... &quot;Jazoon – Jour 1 – Groovy&quot;... que faut-il faire, Scala ou Groovy, ou autre ? Existe-t-il une tendance dans ces salons ?</description> <content:encoded><![CDATA[<p>&#8216;Omniprésence de Scala&nbsp;&raquo;&#8230; &laquo;&nbsp;Jazoon – Jour 1 – Groovy&nbsp;&raquo;&#8230; que faut-il faire, Scala ou Groovy, ou autre ? Existe-t-il une tendance dans ces salons ?</p> ]]></content:encoded> </item> </channel> </rss>
