Journal PHP 5.4 Alpha 1 est annoncé

Posté par  . Licence CC By‑SA.
Étiquettes :
20
20
juin
2011

Bonjour à tous,
Hier soir est tombée l'annonce de la publication de PHP 5.4 Alpha 1.

Je sais bien que l'usage n'est pas d'annoncer la sortie de chaque version mineure et/ou version alpha/beta de n'importe quel logiciel ou langage, mais il s'agit là d'une version un peu particulière : c'est la première sortie d'une nouvelle branche depuis la mort de PHP6, il y a de ça plus d'un an.

Pour les nouveautés de cette version mineure, mais pas tant que ça, je vous laisse consulter l'annonce, loin d'être pauvre.

Et, pour ceux qui ne connaissent pas le blog d'où je tire cette info, je vous invite à le consulter : c'est une vraie mine d'or sur les nouveautés, correctifs, propositions de PHP, l'ambiance qui règne au sein des développeurs de PHP (en gros, il existe 2 camps : ceux qui veulent voir PHP fortement évoluer, et ceux qui sont plutôt conservateurs), ...

  • # Merci

    Posté par  . Évalué à 9.

    Merci pour ce signal de vie de PHP, aussi critiqué que massivement utilisé.

    Bon, je vais songer à passer en php 5.3.x alors ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Merci

      Posté par  (Mastodon) . Évalué à 10.

      aussi critiqué que massivement utilisé.

      Un peu comme Windows...

      • [^] # Re: Merci

        Posté par  (site web personnel) . Évalué à 4.

        Ou COBOL !

        • [^] # Re: Merci

          Posté par  . Évalué à 3.

          Pourrais tu définir "massivement" dans ce cas ?

          </ troll >

      • [^] # Re: Merci

        Posté par  . Évalué à 10.

        Et comme tout ce qui est massivement utilisé.

        « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

        • [^] # Re: Merci

          Posté par  . Évalué à 2.

          On parle de java là, nan ?

          Knowing the syntax of Java does not make someone a software engineer.

  • # Removed legacy features:

    Posté par  . Évalué à 3. 

      . break/continue $var syntax. (Dmitry)
  . Safe mode and all related ini options. (Kalle)
  . register_globals and register_long_arrays ini options. (Kalle)
  . import_request_variables(). (Kalle)
  . allow_call_time_pass_reference. (Pierrick)
  . define_syslog_variables ini option and its associated function. (Kalle)
  . highlight.bg ini option. (Kalle)
  . Session bug compatibility mode (session.bug_compat42 and
    session.bug_compat_warn ini options). (Kalle)
  . session_is_registered(), session_register() and session_unregister() 
    functions. (Kalle)
  . y2k_compliance ini option. (Kalle)

    (Mais il y a toujours les goto...)

    « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

    • [^] # Re: Removed legacy features:

      Posté par  (site web personnel) . Évalué à 5.

      Par contre, PHP 5.4 ajoute les "Traits" ("Horizontal Reuse for PHP"), un truc qui ressemble à de l'héritage multiple (ou un hack pour arriver au même résultat selon moi) :
      https://wiki.php.net/rfc/horizontalreuse

      Comme pour l'ajout des espaces de nommage avec leur syntaxe surprenante et une utilisation peu aisée, cette nouvelle fonctionnalité (son implémentation, sa syntaxe) me laisse perplexe. Durant l'héritage (bloc "use"), on peut changer le nom des méthodes, leur visibilité (public / private / protected), et gérer manuellement la gestion des conflits (si deux "traits" ont des fonctions (méthodes ?) qui ont le même nom). Exemple extrait de la RFC :

       <?php
 class Talker {
   use A, B {
     B::smallTalk insteadof A;
     A::bigTalk insteadof B;
     B::bigTalk as talk;
   }
 }
 ?>

      Python a opéré un changement radical dans Python 2.3 pour corriger des bugs tordus liés à l'héritage multiple. Un nouveau type de classe (new-style class) a été introduit pour implémenter une nouvelle méthode de résolution des méthodes (MRO, method resolution order) : C3 Method Resolution Order. Vieille documentation avec de jolis serpents en ASCII Art :
      http://www.python.org/download/releases/2.3/mro/

      Avec Python 3, les old-style class ont disparu : toutes les classes utilisent l'algorithme C3. Perl 6 et Parrot utilisent également C3, Perl 5.10 peut l'utiliser de manière optionnelle.
      http://en.wikipedia.org/wiki/C3_linearization

      Guido raconte comment Python est passé de son algo de MRO maison à C3 :
      http://python-history.blogspot.com/2010/06/method-resolution-order.html

      Les traits PHP me font plus penser aux mixins Ruby (que je ne connais pas).
      http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html

      Mais bon, l'héritage multiple et les mixins semblent être trop compliqués pour un développeur PHP (extrait de la RFC PHP) :
      To circumvent this problems multiple inheritance and Mixins have been invented. But both of them are complex and hard to understand. PHP5 has been explicitly designed with the clean and successful model of Java in mind: single inheritance, but multiple interfaces.

      • [^] # Re: Removed legacy features:

        Posté par  (site web personnel) . Évalué à 4.

        Les traits ne sont ni plus ni moins que du copier/coller de méthodes à la compilation.
        Rien à voir donc avec les mixins et les classes MRO de python, et c'est effectivement bien plus simple à appréhender, même si, lorsque l'on pousse le principe dans ses retranchements, comme dans l'exemple que tu donnes, la gestion des collisions impose une gymnastique mentale.
        Fort heureusement, elle s'apparente à celle des espaces de nommage.
        J'ai un billet dédié aux traits de PHP, ainsi qu'un support de conférence sur le sujet donné l'année dernière lors d'un rendez-vous AFUP, en partenariat avec Stephan Maar, l'auteur de l'implémentation des traits dans PHP.

        • [^] # Re: Removed legacy features:

          Posté par  (site web personnel) . Évalué à 5.

          J'ai lu http://blog.runpac.com/post/php-point-sur-traits-trunk et je sais maintenant un peu mieux ce qui me dérange.

          Un trait peut accéder aux attributs et méthodes de l'objet sans que ces attributs et méthodes soient définis. Il faut donc espérer que la classe qui utilise le trait respecte les contraintes implicites exigées par le trait. Ce problème peut être limité par l'ajout de méthodes abstraites au trait.

          Les Abstract Base Class (ABC) de Python, genre d'interfaces, déclarent les méthodes abstraites dont elles ont besoin. Si une classe qui l'utilise n'implémente pas toutes les méthodes abstraites, une exception est levée. La plupart des ABC utilisent uniquement des méthodes, ce qui laisse plus de libertés au développeur qui souhaite l'utiliser (pas d'attributs imposés). Mais si une ABC utilise un attribut, c'est elle qui doit le définir. Par exemple, MappingView a un attribut protégé self._mapping qu'elle définit dans son constructeur. KeysView est basé sur MappingView et peut donc réutiliser self._mapping : l'attribut est défini dans MappingView, on sait d'où vient (c'est explicite).

          Documentation des ABC :
          http://docs.python.org/dev/library/collections.abc.html

          Le code (très clair je trouve) :
          http://hg.python.org/cpython/file/default/Lib/collections/abc.py

          La PEP associée (Introducing Abstract Base Classes) :
          http://www.python.org/dev/peps/pep-3119/

  • # Fork

    Posté par  . Évalué à 6.

    Est-ce que cette nouvelle, ne vient pas pour contrer le démarrage du fork ?

    Pour ceux qui n'ont pas vu l'info :
    http://php.developpez.com/actu/33201/Naissance-d-un-fork-de-PHP-fonde-sur-la-version-5-3-6-du-langage-et-lance-par-un-developpeur-allemand/

    • [^] # Re: Fork

      Posté par  (site web personnel) . Évalué à 7.

      Non.
      Le processus de développement de 5.4 est en route depuis la mort de PHP 6, et certains développeurs de PHP poussait très fort pour la sortie d'une alpha bien avant l'annonce de ce fork.
      Il ne faut pas espérer qu'un fork du langage réalisé par un seul homme sans réel légitimité vis à vis de PHP (en terme de réputation et non en terme technique) va bousculer sérieusement les développeurs de PHP.
      Il faudrait pour cela un fork effectué par des développeurs historiques, qui serait suivi par une grosse partie de la communauté, et que de plus les utilisateurs, et notamment les entreprises suivent le mouvement. Et pour cela, il faudrait qu'elles aient confiance dans ce nouveau langage, sa pérennité, etc.
      Bref, ce n'est pas gagné.

  • # passage de 5 à 6 => palier maudit ?

    Posté par  . Évalué à 6.

    Je pense que le fait que PHP6 soit abandonné devrait faire réfléchir Larry Wall et la communauté Perl. Ca fait des années qu'on nous parle de Perl6.

    Sinon, Hurd était en version 6 ? Ou sont les autres versions ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.