Facebook a des problemes avec le codage en PHP, alors ils inventent une version java-ifiee de PHP!
Ce n'est pas le sentiment que j'ai. Alors oui il y à un existant, et cet effort est probablement celui qui répond bien à toutes es contraintes.
Plutôt que de changer de langage, ce qui serait extrêmement coûteux dans leurs cas apparemment.
Mais, comme tu le rappels, il y à xhp. Qui fait plus que du simple templating. Avec leurs systèmes tu as des contraintes, de l'héritage vertical, et peut être horizontal (si tant est que ce soit utile) à vérifier.
Ce qui intéressant aussi c'est que pour une fois, il me semble, on vient de faire le total opposé de la doctrine mvc. Ils ont mis le code de présentation dans le langage de développement (pas nécessairement la couche métier, hein).
Ce qui me fait dire qu'ils n'ont pas simplement cherché à patcher le langage pour en améliorer la maintenance, ou copier ce qui c'est fait ailleurs, ils ont vraiment fait évoluer le langage.
En fait je pense qu'ils retournent à ce qu'était php au départ, un pur langage de template.
Sauf que là on à un langage de template dopé au stéroide1000, qui ne fait que cela, et qui le fait bien.
Et en plus tu peux faire d'autres trucs à côté, car on ne sait jamais.
Les types que tu cites, je n'en vois pas trop l’intérêt moi non plus.
Maintenant voici ce qu'ils en disent :
Given the wide range of functionality offered by PHP arrays, they can be used to mimic common specialized collection types such as vectors, dictionaries, and sets. So why extend HHVM with its own collection classes and functionality? One key reason is code clarity. It's not always clear in PHP how an array is being used, or what the types of the keys and values are. This makes it harder to confidently make changes to a larger codebase without introducing subtle bugs. Another key reason is PHP array performance. Generally speaking, it is impossible to know with certainty if a PHP array is going to be used as a vector, as a map, as a set, etc., and as such the code generated by HHVM and associated data structures are more complex. Also, PHP arrays are copy-on-write. This means that programmers must use PHP references when they don't want the array to be copied, and using PHP references generally degrades code performance. Enter the Hack collection classes.
Finalement, Java sait tout faire, ou presque, il me semble. Mais apparemment ce n'est pas suffisant.
[^] # Re: The Hack language : PHP avec un peu de typage statique ?
Posté par maboiteaspam . En réponse à la dépêche The Hack language : PHP avec un peu de typage statique. Évalué à 3.
Ce n'est pas le sentiment que j'ai. Alors oui il y à un existant, et cet effort est probablement celui qui répond bien à toutes es contraintes.
Plutôt que de changer de langage, ce qui serait extrêmement coûteux dans leurs cas apparemment.
Mais, comme tu le rappels, il y à xhp. Qui fait plus que du simple templating. Avec leurs systèmes tu as des contraintes, de l'héritage vertical, et peut être horizontal (si tant est que ce soit utile) à vérifier.
Ce qui intéressant aussi c'est que pour une fois, il me semble, on vient de faire le total opposé de la doctrine mvc. Ils ont mis le code de présentation dans le langage de développement (pas nécessairement la couche métier, hein).
Ce qui me fait dire qu'ils n'ont pas simplement cherché à patcher le langage pour en améliorer la maintenance, ou copier ce qui c'est fait ailleurs, ils ont vraiment fait évoluer le langage.
En fait je pense qu'ils retournent à ce qu'était php au départ, un pur langage de template.
Sauf que là on à un langage de template dopé au stéroide1000, qui ne fait que cela, et qui le fait bien.
Et en plus tu peux faire d'autres trucs à côté, car on ne sait jamais.
Les types que tu cites, je n'en vois pas trop l’intérêt moi non plus.
Maintenant voici ce qu'ils en disent :
Finalement, Java sait tout faire, ou presque, il me semble. Mais apparemment ce n'est pas suffisant.