Ich verwalte eine für PHP 5.2 geschriebene Bibliothek und möchte eine PHP 5.3-Namespace-Version davon erstellen. Ich würde jedoch auch die Version ohne Namespace auf dem neuesten Stand halten, bis PHP 5.3 so alt ist, dass sogar Debian Stable es ausliefert 😉

Ich habe ziemlich sauberen Code, ungefähr 80 Klassen folgen Project_Directory_Filename Namensschema (ich würde sie ändern in \Project\Directory\Filename natürlich) und nur wenige Funktionen und Konstanten (auch mit vorangestelltem Projektnamen).

Die Frage ist: Was ist der beste Weg, um Namespace- und Nicht-Namespace-Versionen parallel zu entwickeln?

• Soll ich einfach einen Fork im Repository erstellen und Änderungen zwischen Branches zusammenführen? Gibt es Fälle, in denen mit Backslash gesprenkelter Code schwer zusammenzuführen ist?

• Soll ich ein Skript schreiben, das die Version 5.2 in 5.3 konvertiert oder umgekehrt? Sollte ich den PHP-Tokenizer verwenden? sed? C-Präprozessor?

• Gibt es eine bessere Möglichkeit, Namespaces zu verwenden, wo verfügbar, und die Abwärtskompatibilität mit älterem PHP aufrechtzuerhalten?

Aktualisieren: Habe mich doch gegen die Verwendung von Namespaces entschieden.

Ich denke nicht, dass die Vorverarbeitung des 5.3-Codes eine großartige Idee ist. Wenn Ihr Code in PHP 5.2 und 5.3 funktional identisch ist, mit Ausnahme der Verwendung von Namespaces anstelle von durch Unterstriche getrennten Präfixen, warum sollten Sie dann überhaupt Namespaces verwenden? In diesem Fall klingt es für mich so, als ob Sie Namespaces verwenden möchten, um Namespaces zu verwenden.

Ich denke, Sie werden feststellen, dass Sie bei der Migration zu Namespaces anfangen werden, etwas anders über die Organisation Ihres Codes nachzudenken.

Aus diesem Grund stimme ich Ihrer ersten Lösung nachdrücklich zu. Erstellen Sie einen Fork und führen Sie Backports von Funktionen und Bugfixes durch.

Viel Glück!

Dies ist eine Fortsetzung meiner vorherigen Antwort:

Der Namespace-Simulationscode wurde ziemlich stabil. Ich kann Symfony2 bereits zum Laufen bringen (einige Probleme immer noch, aber im Grunde). Allerdings fehlen noch einige Dinge wie die Auflösung von Variablennamensräumen für alle Fälle, abgesehen von new $class.

Jetzt habe ich ein Skript geschrieben, das rekursiv durch ein Verzeichnis iteriert und alle Dateien verarbeitet: http://github.com/nikic/prephp/blob/master/prephp/namespacePortR.php

Gebrauchsanweisung

Anforderungen, damit Ihr Code funktioniert

Ihre Klassennamen dürfen nicht enthalten _ Charakter. Wenn dies der Fall ist, können Klassennamen beim Konvertieren mehrdeutig werden.

Ihr Code darf keine globalen Funktionen oder Konstanten innerhalb eines Namespaces neu deklarieren. Dadurch wird sichergestellt, dass Ihr gesamter Code zur Kompilierzeit aufgelöst werden kann.

Grundsätzlich sind dies die einzigen Einschränkungen für Ihren Code. Ich sollte jedoch beachten, dass der NamespacePortR in einer Standardkonfiguration Dinge wie nicht auflöst $className="Some\\NS\\Class"; new $className, da hierfür zusätzlicher Code eingefügt werden müsste. Es ist besser, dass dies später gepatcht wird (entweder manuell oder mithilfe eines automatisierten Patch-Systems).

Aufbau

Da wir davon ausgegangen sind, dass keine globale Funktion oder Konstante in einem Namensraum neu deklariert wird, müssen Sie die assumeGlobal Klassenkonstante in der Namespace-Listener. Legen Sie in derselben Datei die SEPARATOR konstant zu _.

Ändern Sie im NamespacePortR den Konfigurationsblock entsprechend Ihren Anforderungen.

PS: Das Skript kann bereitgestellt werden a ?skip=int Möglichkeit. Dies sagt ihm, den ersten zu überspringen int Dateien. Sie sollten es nicht benötigen, wenn Sie den Override-Modus auf intelligent eingestellt haben.

Hier ist, was ich gefunden habe:

Dies mit regulären Ausdrücken zu tun, ist ein Albtraum. Sie können das meiste mit nur ein paar einfachen Ausdrücken erledigen, aber dann sind Grenzfälle ein Killer. Am Ende habe ich ein schreckliches, zerbrechliches Durcheinander, das kaum mit einer Codebasis funktioniert.

Es ist mit einem eingebauten Tokenizer und einem einfachen rekursiven Abstiegsparser machbar, der nur eine vereinfachte Teilmenge der Sprache verarbeitet.

Am Ende hatte ich ein ziemlich hässliches Design (Parser und Transformer in einem – meistens nur das Ändern oder erneute Ausgeben von Token), weil es zu viel Arbeit schien, einen nützlichen Syntaxbaum mit beibehaltenen Leerzeichen zu erstellen (ich wollte, dass der resultierende Code für Menschen lesbar ist). ).

Ich wollte es versuchen phc dafür, konnte ihn aber nicht überzeugen configure dass ich die erforderliche Version der Boost-Bibliothek erstellt habe.

Ich habe ANTLR dafür noch nicht ausprobiert, aber es ist wahrscheinlich das beste Tool für diese Art von Aufgaben.

Ich arbeite an einem Projekt, das PHP 5.3 auf PHP 5.2 emuliert: prephp. Es enthält Namespace-Unterstützung (allerdings noch nicht vollständig).

Nun, aus der Erfahrung heraus, dies zu schreiben, gibt es ein Mehrdeutigkeitsproblem Namensraumauflösung: Unqualifizierte Funktionsaufrufe und konstante Lookups haben einen Fallback auf den globalen Namensraum. Sie könnten Ihren Code also nur dann automatisch konvertieren, wenn Sie alle Ihre Funktionsaufrufe/Konstantensuchen entweder vollständig qualifiziert oder qualifiziert haben oder wenn Sie keine Funktion oder Konstante in einem Namespace mit demselben Namen wie eine in PHP eingebaute Funktion neu definiert haben.

Wenn Sie sich strikt an diese Vorgehensweise halten (welche auch immer Sie wählen), wäre es ziemlich einfach, Ihren Code zu konvertieren. Es wäre eine Teilmenge des Codes zum Emulieren von Namespaces in Prephp. Falls ihr Hilfe bei der Umsetzung braucht, könnt ihr mich gerne fragen, ich wäre interessiert 😉

PS: Der Namespace-Emulationscode von prephp ist noch nicht vollständig und kann fehlerhaft sein. Aber es kann Ihnen einige Einblicke geben.

Hier ist die beste Antwort, die Sie meiner Meinung nach finden werden:

Schritt 1: Erstellen Sie ein Verzeichnis namens 5.3 für jedes Verzeichnis mit php5.3-Code darin und kleben Sie den gesamten 5.3-spezifischen Code hinein.

Schritt 2: Nehmen Sie eine Klasse, die Sie in einen Namensraum einfügen möchten, und tun Sie dies 5.3/WebPage/Consolidator.inc.php:

namespace WebPage;
require_once 'WebPageConsolidator.inc.php';

class Consolidator extends \WebpageConsolidator
{
    public function __constructor()
    {
        echo "PHP 5.3 constructor.\n";

        parent::__constructor();
    }
}

Schritt 3: Verwenden Sie eine Strategiefunktion, um den neuen PHP 5.3-Code zu verwenden. In nicht-PHP5.3 findclass.inc.php platzieren:

// Copyright 2010-08-10 Theodore R. Smith <phpexperts.pro>
// License: BSD License
function findProperClass($className)
{
    $namespaces = array('WebPage');

    $namespaceChar="";
    if (PHP_VERSION_ID >= 50300)
    {
        // Search with Namespaces
        foreach ($namespaces as $namespace)
        {
            $className = "$namespace\\$className";
            if (class_exists($className))
            {
                return $className;
            }
        }

        $namespaceChar = "\\";
    }

    // It wasn't found in the namespaces (or we're using 5.2), let's search global namespace:
    foreach ($namespaces as $namespace)
    {
        $className = "$namespaceChar$namespace$className";
        if (class_exists($className))
        {
            return $className;
        }
    }

    throw new RuntimeException("Could not load find a suitable class named $className.");
}

Schritt 4: Schreiben Sie Ihren Code so um, dass er so aussieht:

<?php
require 'findclass.inc.php';

$includePrefix = '';
if (PHP_VERSION_ID >= 50300)
{
        $includePrefix = '5.3/';
}

require_once $includePrefix . 'WebPageConsolidator.inc.php';

$className = findProperClass('Consolidator');
$consolidator = new $className;

// PHP 5.2 output: PHP 5.2 constructor.
// PHP 5.3 output: PHP 5.3 constructor. PHP 5.2 constructor.

Dass Wille Arbeite für dich. Es ist ein leistungsmäßiger Schlag, aber nur ein kleiner, und wird beseitigt, wenn Sie sich entscheiden, die Unterstützung von 5.3 einzustellen.

Was ich getan habe, mit einer großen Codebasis, die (unter anderem) die Unterstrich-Namenskonvention verwendete, und require_once eine ganze Menge anstelle eines Autoloaders, war es, einen Autoloader zu definieren und hinzuzufügen class_alias Zeilen in den Dateien, die Aliase für den alten Namen einer Klasse definieren, nachdem ihre Namen geändert wurden, um mit Namespaces gut zu sein.

Ich habe dann angefangen zu entfernen require_once Anweisungen, bei denen die Ausführung nicht von der Einschlussreihenfolge abhängig war, da der Autoloader Sachen und Namespace-Sachen aufsammelte, während ich Fehler behob und so weiter.

Es hat bisher ganz gut funktioniert.

Nun, ich weiß nicht, ob es der “beste” Weg ist, aber theoretisch könnten Sie ein Skript verwenden, um Ihren 5.3-Migrationscode zu nehmen und ihn in 5.2 zurückzuportieren (möglicherweise sogar mit PHP).

An Ihren Namespace-Dateien möchten Sie etwas konvertieren:

namespace \Project\Directory\Filename;

class MyClass {
  public $attribute;

  public function typedFunction(MyClass $child) {
    if ($child instanceof MyClass) {
      print 'Is MyClass';
    }
  }
}

Zu etwas wie:

class Project_Directory_Filename_MyClass {
  public $attribute;

  public function typedFunction(Project_Directory_Filename_MyClass $child) {
    if ($child instanceof Project_Directory_Filename_MyClass) {
      print 'Is MyClass';
    }
  }
}

Und in Ihrem Namespace-Code müssten Sie konvertieren von:

$myobject = new Project\Directory\Filename\MyClass();

Zu:

$myobject = new Project_Directory_Filename_MyClass();

Während alle Ihre includes und requires würde gleich bleiben, ich denke, Sie müssten fast eine Art Cache aller Ihrer Klassen und Namensräume aufbewahren, um die komplexe Konvertierung um die ‘instanceof’- und typisierten Parameter durchzuführen, wenn Sie sie verwenden. Das ist das Schwierigste, was ich sehen kann.