dedlfix: Endekennzeichnung einer PHP-Datei

Beitrag lesen

Tach!

Genau! So antworten Leute, die nicht selber nachdenken und meine Ideen von vornherein als Unfug abtun. Tatsächlich wird eine jede Idee auch Unfug bleiben, wenn sie auf ihre Umsetzung und Nebenwirkungen nicht umfangreich geprüft wird. Dem Sven danke ich für seinen Hinweis auf den OpCode-Cache, aber es ist nur eine Frage der Zeit, bis auch PHP einen eval'd Code cachen kann, der Request ist bereits unterwegs, und: Was sagt uns das? Richtig, die Idee ist gar nicht mal so schlecht (und die ist nicht einmal von mir) ;)

Der Op-Code-Cache muss sich bei Dateien lediglich den Dateinamen (inklusive Pfad) merken und kann dazu dann den gecachten Code hervorzaubern. eval'd Code hat außer sich selbst keine eindeutigen Metadaten, um ihn wiedererkennen zu können. Der Cache müsste sich also den gesamten Code merken, um wiederzuerkennen dass es derselbe ist, oder eine eindeutige Prüfsumme bilden. Wenn die einigermaßen sicher sein soll, kommt man kaum um cryptografische Hash-Methoden umhin, und dann frisst der Performanceverlust des Hash-Errechnens den Cache-Gewinn ein ganzes Stück weit wieder auf. Auf alle Fälle deutlich mehr als das Vergleichen von Dateinamen.

<?php
// kein Problem, das steht links oben in der Ecke, sieht jeder ;)
return 1; // das ist die Idee: Hier ist definitiv Schluss
?>

Hier kann stehen, was will... oder vielleicht sogar was Sinnvolles, was nicht in den Buffer soll, eine kleine Doku vielleicht...

  
Diese Funktionalität [gibt es bereits](http://de3.php.net/manual/en/function.halt-compiler.php).  
  

> > Und wo ist der Vorteil gegenüber dem Weglassen von "?>"?  
> Ohje, ist das wirklich so schwer, diesen Vorteil zu erkennen!?  
> Kleiner Tipp: Der Code ist besser lesbar. Und nochn Tipp: return kann auch was zurückgeben ;)  
  
return kann auch in herkömmlich ausgezeichneten Include-Dateien etwas zurückgeben. Und welcher Code konkret soll besser lesbar sein?  
  
Falls du das nach deiem Vorschlag weglassbare <?php am Anfang meinst, das erhöht die Lesbarkeit nicht merklich. Die Nachteile sind aber weitaus gravierender. Nicht nur, dass der Code nicht vom OP-Code-Cache abgedeckt werden kann, brauchst du nun zwei Funktionsaufrufe (inklusive 4 Klammern) statt eines include-Statements (ohne Klammern). Zudem geht dir die Funktionalität der \_once-Variante verloren. (Na klar kann man die mit viel Code nachbauen, aber warum?) Weiterhin werden auch alle Tools nicht mehr richtig funktionieren, mit denen man sich durch Features wie Syntaxhervorhebung und Codevervollständigung die Arbeit erleichtert. Das alles steht in keinem Verhältnis zu einem simplen <?php.  
  
  
dedlfix.