Clever Geek Handbook

Mir gefällt nicht, was aus PHP wird





Und ich weiß bereits, was Sie sagen werden, wenn Sie sich den Titel des Artikels ansehen:

- Wer sind Sie? Warum erlaubst du dir das zu sagen?



Ich werde sofort antworten, damit es keine Auslassungen gibt:



  • Ich programmiere seit 2004 professionell in PHP, das heißt zum Zeitpunkt dieses Schreibens 16 Jahre lang, und das mache ich jeden Tag weiter.
  • Ich unterrichte seit ungefähr 10 Jahren Programmieren, einschließlich PHP, und während dieser Zeit habe ich mehrere tausend Studenten freigelassen
  • Ich war immer begeistert von jeder neuen Version von PHP, die aus der Zeit von 5.0 bis 7.4 herauskam, und war immer ein Anhänger des Ansatzes "Auf die neueste Version schreiben, auf die nächste testen".


Und trotz alledem gefällt mir nicht, was aus PHP jetzt wird und was es bald sein wird, buchstäblich diesen Herbst.



Fast jeder in PHP 8 verwendete RFC verursacht mir Schmerzen und Verwirrung. Und ich bin bereit, meine Position zu erklären und zu verteidigen.



Grundlegende Sprachkonzepte ändern sich



Wie beginnt das Erlernen einer neuen Sprache normalerweise? Werte, Ausdrücke, Variablen und Funktionen. Ebenso ist das Erlernen von PHP die natürliche Reihenfolge.



Wenn wir anfangen, Funktionen durchzugehen, mache ich die Schüler besonders darauf aufmerksam, dass in PHP der Kontext von Funktionen geschlossen und "versiegelt" ist. Dies ist sehr einfach und völlig logisch - Sie müssen sich nur klar merken, welche Namen die Funktion sieht: ihre Argumente und ihre internen Variablen.



Wenn wir zu den Grundlagen von OOP kommen und das Konzept der "Methode" lernen, verlassen wir uns auf das Konzept einer Funktion und fügen dem Kontext eine weitere Klausel hinzu: $ this in dynamischen Methoden. Ändert sich noch etwas? Nein. Die Funktionen sind noch geschlossen, ihr Kontext hört nach dem Aufruf auf zu existieren, nichts fließt von außen in die Funktion und auch nichts fließt aus ihr heraus.



Wir kommen zu anonymen Funktionen - und auch hier ändern sich die Spielregeln nicht. Argumente? Ja. Interne Variablen? Ja. $ das? OK, lassen Sie uns diese Frage umgehen, sonst müssen wir eine seltsame Sache namens "statische anonyme Funktion" diskutieren :)



Als nächstes fügen wir das Konzept der "Schließung" hinzu. Auch bei ihm ist alles logisch, ein separates Schlüsselwort, eine endgültige Liste von Variablen aus dem Erstellungskontext, die Grundprinzipien werden nicht verletzt. Und da der Wert geschlossen ist, nicht der Name, ist im Allgemeinen alles in Ordnung - die Funktionen bleiben weiterhin "versiegelt". Nichts von außen wird versickern, nichts wird herausfließen.



Weißt du was als nächstes passiert?



Und dann haben wir Pfeilfunktionen. Und es bricht alles.



Ich muss erklären, dass Pfeilfunktionen gegen schwer zu erlernende Prinzipien verstoßen, da sie sich zum Zeitpunkt ihrer Erstellung im GESAMTEN Kontext befinden.



Ops.



Aber was ist mit dem Prinzip der "Enge"? Aber in irgendeiner Weise haben sie sich nicht darum gekümmert, um das Schreiben zu vereinfachen und 6 Zeichen zu sparen - jetzt haben wir "fn" anstelle von "function".



Schlecht. Inkonsistent.



Denken Sie, dass dies das einzige Beispiel ist? Egal wie es ist.



Stellen Sie jedem Noob eine Frage - mit welchem ​​Charakter beginnen Namen in PHP? Das ist richtig, mit dem "$"



  • Variablennamen
  • Objekteigenschaftsnamen
  • Namen von Klasseneigenschaften
  • Argumentnamen
  • sogar "variable Variablen" sind auch "$"!


Ist es logisch? Ja. Konsequent? Ja. Sie müssen sich nur an die Konstanten erinnern, die $ nicht benötigen.



Was haben wir jetzt? Benannte Argumente: wiki.php.net/rfc/named_params 



array_fill(value: 50, num: 100, start_index: 0);


Wo ist der "Dollar"? Nein.



Das ist ein Problem.



Jetzt müssen Sie sich daran erinnern, dass Sie "Dollar" in die Signatur der Funktion schreiben müssen, aber nicht, wenn Sie aufgerufen werden. Und dies ist ein sehr ernstes Problem, das das integrale System der Sprache verletzt. Das ist schlecht und inkonsistent.



Wofür? Ja, nur weil jemand ohne nachzudenken Zucker von Python auf PHP übertragen wollte. Python verwendet jedoch mindestens dasselbe "=" - Symbol, um Name und Wert sowohl in der Zuweisung als auch in den benannten Argumenten abzugleichen, und jetzt haben wir zwei davon - das übliche "=" und ":" in der neuen Konstruktion.



Fast jeder für PHP 8 diskutierte RFC hat das gleiche Problem - eine Verletzung des zuvor etablierten Sprachsystems. Und das ist schlecht. Es bricht den Verstand sowohl für diejenigen, die schon lange in PHP schreiben, als auch für diejenigen, die gerade erst anfangen, es zu lernen.



Sehen: (wiki.php.net/rfc/match_expression_v2 ) 



echo match (1) {
    0 => 'Foo',
    1 => 'Bar',
    2 => 'Baz',
};


Dies sind neue Übereinstimmungsausdrücke. Können Sie erklären, warum sie das Symbol "=>" und nicht den üblichen Schalterfall ":" verwenden? Ich kann auch nicht.



Dies ist wiederum eine Verletzung eines bereits etablierten Systems. Das Symbol "=>" hat immer (bevor der verdammte Pfeil funktioniert, wieder!) Das Trennzeichen eines Schlüssel-Wert-Paares bezeichnet. Jetzt bezeichnet es auch das Trennzeichen der Argumentliste und den Rückgabewert im "Pfeil" und das Auswahlzeichen im Übereinstimmungsoperator.



Das ist schlecht. Das ist sehr schlecht. Dies ist sehr inkonsistent. Dies ist noch schlimmer als das statische Schlüsselwort, das mindestens drei grundlegend unterschiedliche Bedeutungen hat.



Unlesbarkeit in natürlicher Sprache



Zeigen Sie den englischen Muttertext an 



SELECT * 
FROM users
WHERE age>=18 AND name LIKE 'J%'


und wenn sein IQ 60 überschreitet, wird er leicht erklären, worum es in diesem Text geht und was bei der Implementierung dieses Textes als Programm getan wird.



Zeigen Sie einem Genie, das mit JS nicht vertraut ist, den Text 



const f = () => 42;


und er wird nichts verstehen. Konstante? f sind diese Klammern? Gehen die Klammern zu einer Zahl? Was ist das?



Ich war immer froh, dass PHP der Kürze halber weit davon entfernt ist, die Lesbarkeit zu beeinträchtigen. Ich war froh, dass es weit entfernt von JS war, wo das Prinzip der Code-Lesbarkeit zugunsten von "weniger Zeichen schreiben, niemand wird diesen Code sowieso lesen" aufgegeben wurde.



Jetzt wurde mir klar, dass PHP 8 das Prinzip der natürlichen Lesbarkeit brechen würde. Und anscheinend unwiderruflich.



Schauen Sie sich einfach diese Beispiele an:



wiki.php.net/rfc/constructor_promotion 



class Point {
    public function __construct(
        public float $x = 0.0,
        public float $y = 0.0,
        public float $z = 0.0,
    ) {}
}


Anstelle von Konstruktorargumenten deklarieren wir jetzt sofort Eigenschaften und legen ihre Werte aus den Argumenten fest.



Ratet mal, was nach den "=" Zeichen steht? Anfängliche Eigenschaftswerte? Oder die Standardwerte der Konstruktorargumente? Es ist unmöglich zu erraten. Finden Sie es heraus, indem Sie auch den Code lesen. Das ist schlecht. Ein weiterer Ort, um auswendig zu lernen.



wiki.php.net/rfc/property_write_visibility 



class User {
    public:private int $id;
    public:protected string $name;
}


Öffentlich-privates Eigentum? Ernsthaft? Wie kann man aus diesem Code verstehen, dass es sich um eine lesbare Eigenschaft und eine beschreibbare Eigenschaft handelt?



wiki.php.net/rfc/conditional_break_continue_return 



    function divide($dividend, $divisor = null) {
        return if ($divisor === null || $divisor === 0): 0; 
        return $dividend / $divisor;
    }


Im Ernst, braucht jemand das? Jemand schrieb jahrelang in PHP und litt darunter, dass er nicht "return ... if" anstelle von "if ... return" schreiben konnte? Brauchen wir wirklich eine neue Yoda-Syntax für das banale if und return?



Zu viele Möglichkeiten, um dasselbe zu tun



PHP hat immer gegen das berühmte Prinzip "Es sollte nur einen Weg geben ..." verstoßen. Aber es hat es intelligent, nach und nach und vernünftig gemacht.



Jetzt wurde dieses Prinzip mit Füßen getreten und zerstört. Jeder akzeptierte RFC sagt: "Fügen wir eine andere Schreibweise hinzu, wenn, weil ich dies in Perl / Python / Ruby / Brainfuck gesehen habe!" - und andere Begründungen, außer "Ich habe gesehen", werden im Allgemeinen nicht gegeben.



Was war: 



if ($y == 0)
  return 0;

if ($y == 0) {
  return 0;
}

if ($y == 0):
  return 0;
endif;


- bis zu drei Möglichkeiten, dasselbe aufzunehmen. Nicht sehr gut, müssen Sie erklären: Warum gibt es drei davon, warum sollten Sie keinen Code ohne Operatorklammern schreiben und warum Sie eine alternative Syntax benötigen.



Das reicht aber nicht! Warten Sie etwas länger und Sie werden sehen: 



//  -If
return if ($y == 0): 0;


So wurden die Funktionen aufgerufen: 



foo(bar($baz));


Sie werden dies bald sehen: 



$baz |> 'bar' |> 'foo'


- Genial, nicht wahr? Es ist sofort klar, dass dies ein Funktionsaufruf ist!



Und ich habe noch nichts über Pfeilfunktionen geschrieben :)



Immer mehr Möglichkeiten, das, was zuvor getan wurde, ohne Probleme zu tun:



  • Übereinstimmungsausdrücke
  • Operator "? ->"
  • zwei verschiedene Syntaxen zum Schließen
  • Schleife + sonst
  • statische Konstruktoren
  • Eigenschaftsdeklarationen in Konstruktorargumenten (!)


und vieles mehr, wodurch der Code nur schwerer zu lesen und die Sprache schwerer zu lernen ist.



Ergebnis



PHP entwickelt sich weiter. Dies ist ein wichtiger Prozess, der eine große Anzahl von Menschen und die gesamte Programmiergemeinschaft betrifft.



Es entsteht jedoch das Gefühl, dass die Entwicklung irgendwo schief läuft. Ich befürchte, dass die angenommenen Änderungen die Sprache dazu führen werden, dass die darin enthaltenen Programme immer kürzer und weniger lesbar werden, dass sie immer mehr Möglichkeiten bieten, dasselbe auf unterschiedliche Weise zu tun und all diese Methoden zu erlernen es dauert immer mehr Zeit.



Ich möchte in einem Jahr kein neues Perl anstelle von PHP sehen. Und Ihnen?


More articles:


All Articles