Endekennzeichnung einer PHP-Datei

[Hanni]

Hallo,
irgendwo hatte ich gelesen, dass das ?> am Ende einer PHP-Datei "depreciated" ist.
Gilt dies für alle Dateien (rufende und gerufene)?

[Der Martin]

Hi,

irgendwo hatte ich gelesen, dass das ?> am Ende einer PHP-Datei "depreciated" ist.

das trifft's nicht ganz. Aber es gilt als guter Rat, diese Endemarkierung wegzulassen, denn damit verhindert ma sehr wirksam, dass am Ende ungewollt eine Ausgabe an den Client erfolgt (z.B. ein Leerzeichen oder ein Zeilenumbruch).

Gilt dies für alle Dateien (rufende und gerufene)?

Ja.

So long,
 Martin

[hotti]

hi,

das trifft's nicht ganz. Aber es gilt als guter Rat, diese Endemarkierung wegzulassen, denn damit verhindert ma sehr wirksam, dass am Ende ungewollt eine Ausgabe an den Client erfolgt (z.B. ein Leerzeichen oder ein Zeilenumbruch).

Es gäbe noch eine andere Möglichkeit, dies zu verhindern, dazu werden beide Tags (<?php .. ?>) weggelassen, eine Klassen-Datei sähe dann z.B. so aus:

  
class Foo{}  
return 1;  

D.h., die Datei enthält nur noch den Code. Das Einbinden erfolgt dann nicht mit include/require, statdessen wird die Datei mit file_get_contents() eingelesen und deren Inhalt an eval() übergeben. Wichtig ist die letzte Zeile return(1); somit kann geprüft werden, ob die Kompilierung per eval bis dahin durchgelaufen ist. Interessant ist in diesem Zusammenhang der zweite optionale Parameter für file_get_contents() womit die Datei aus dem include_path gelesen werden kann, ohne diesen Pfad extra angeben zu müssen.

Hotti

[ChrisB]

Hi,

Es gäbe noch eine andere Möglichkeit […]

Auweia, typischer Hotti-Unfug mal wieder.

MfG ChrisB

[Tabellenkalk]

Hallo?

Auweia, typischer Hotti-Unfug mal wieder.

MfG ChrisB

das liest sich wie ein PA, stattdessen fehlen mir irgendwie Argumente alá "Das haben wir noch nie so gemacht" oder so...

Gruß
Kalk

[hotti]

hi,

das liest sich wie ein PA, stattdessen fehlen mir irgendwie Argumente alá "Das haben wir noch nie so gemacht" oder so...

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) ;)

Aber ich habe noch eine Idee, was einen versehentlich erzeugen OutBuffer verhindert:

  
<?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...  
  

Hotti

[M.]

<?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...

  
Und wo ist der Vorteil gegenüber dem Weglassen von "?>"?

[hotti]

<?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...

>   
> 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 ;)  
  
Hotti

-- 
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.

[dedlfix]

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.

[hotti]

hi,

return kann auch in herkömmlich ausgezeichneten Include-Dateien etwas zurückgeben. Und welcher Code konkret soll besser lesbar sein?

Ach was ;)

Besser lesbar als 'gar nichts' ist der Funktionsname 'return';

Hotti

[M.]

Besser lesbar als 'gar nichts' ist der Funktionsname 'return';

Also ist für dich unnötiger Code besser lesbar als "gar nichts"?
Seltsame Ansicht, da jeglicher Code grundsätzlich "komplizierter" ist, als eine Leerzeile oder einfach das Dateiende.

Du solltest unbedingt noch was hinter das return schreiben, ds könnte den Code noch einfacher lesbar machen, weil der Code noch mehr unnütz verlängert wird ..... (Vorsicht, da könnte irgendwo Ironie versteckt sein)

[ChrisB]

Hi,

Genau! So antworten Leute, die nicht selber nachdenken und meine Ideen von vornherein als Unfug abtun.

So antwortete ich, weil ich es leid bin, auf deine halbgaren Ideen jedes Mal näher einzugehen.

Tatsächlich wird eine jede Idee auch Unfug bleiben, wenn sie auf ihre Umsetzung und Nebenwirkungen nicht umfangreich geprüft wird.

Die Idee ist so schon Unfug.

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

Aha, und dann werden wir endlich die Möglichkeit haben, Klassendefinitionen ohne führendes, „störendes“ <?php in Dateien zu notieren, und sie per eval „einzubinden“. Gibt es eine besonders dämliche Art von Programmierern, die genau darauf warten, oder …?

MfG ChrisB

[Fred Furunkelstein 2013]

Genau! So antworten Leute, die nicht selber nachdenken und meine Ideen von vornherein als Unfug abtun.

Naja, also, äh, hotti...

Diese Idee ist wirklich wenig durchdacht. Allein wenn ich mal bei include, include_once, require, require_once und auf die möglichen Notizen/Fehlerbehandlung schaue, dann ist das  Einlesen einer Textdatei in eine Varibale und das nachfolgende eval($str) keine wirklich gute Idee, weil zu viel (Programmier- und Interpretier-)Arbeit.

Falls es aber darum geht Konfigurationen einzulesen ist parse_ini_file() ein fertiges und leicht zu durchschauendes Instrument, die Syntax der ini-Datei ist auch jedem geläufig, der sich mit win.ini und system.ini in den alten Zeiten herumschlagen durfte.

[Fred Furunkelstein 2013]

<?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...

  
Menno! Das wird so gemacht:  
  
  
~~~php
<?php  
/*  
  [link:http://www.phpdoc.de/doc/doccomments.html@title=Hier soll eine kleine Doku stehen]  
*/  
function foo() {  
    /*  
      [link:http://www.phpdoc.de/doc/doccomments.html@title=Hier soll eine kleine Doku stehen]  
    */  
    return 'bar';  
}

[hotti]

hi,

Menno! Das wird so gemacht:

<?php

/*
  [link:http://www.phpdoc.de/doc/doccomments.html@title=Hier soll eine kleine Doku stehen]
/
function foo() {
    /
      [link:http://www.phpdoc.de/doc/doccomments.html@title=Hier soll eine kleine Doku stehen]
    */
    return 'bar';
}

  
Oder einfach nur so:  
`$cfg['DATA'] = require($path);`{:.language-php}  
  
Hotti ;)

[Fred Furunkelstein 2013]

Oder einfach nur so:

<?php  

> $cfg['DATA'] = require($path);  

print_r($cfg); # (von mir hinzugefügt  

Array
(
    [DATA] => 1
)

Ist es das, was Du wolltest? In der von mir includierten Datei stand:

<?php  
$foo="bar";  

Das gleiche Ergebnis, wenn nur

foo="bar";

drin steht...

[Sven Rautenberg]

Moin!

Es gäbe noch eine andere Möglichkeit, dies zu verhindern,

[...]

file_get_contents() eingelesen und deren Inhalt an eval() übergeben.

Das ist herber Blödsinn. Es funktioniert technisch, verhindert aber effektiv die Nutzung von Opcode-Caches, ist folglich also Gift für Performance, und widerspricht auch jeglichem "Common Sense".

- Sven Rautenberg

[hotti]

hi,

[..]verhindert aber effektiv die Nutzung von Opcode-Caches

Kannst du das bitte mal ein bischen näher erläutern?

Vielen Dank,
Hotti

[Sven Rautenberg]

Moin!

hi,

[..]verhindert aber effektiv die Nutzung von Opcode-Caches

Kannst du das bitte mal ein bischen näher erläutern?

Opcode-Caches dienen dazu, die Opcodes, die durch das Kompilieren des PHP-Sources einer Datei entstehen, zwischenzuspeichern. Beim Includieren derselben Datei kürzt der Opcode-Cache den Parse- und Kompiliervorgang ab und sorgt so für Beschleunigung.

Bei eval() gibt es keine Datei und keinen Opcode-Cache-Support.

Ein weiterer Nachteil deiner "Lösung": Dateien liegen in einem Zustand auf dem Server, der kein Parsing provoziert - der Quellcode ist deshalb viel leichter unabsichtlich zugänglich.

- Sven Rautenberg

[hotti]

moin,

Bei eval() gibt es keine Datei und keinen Opcode-Cache-Support.

Danke!

[dedlfix]

Tach!

irgendwo hatte ich gelesen, dass das ?> am Ende einer PHP-Datei "depreciated" ist.

deprecated != depreciated. Weder das eine noch das andere. Im PHP-Handbuch ist nur allgmein die Möglichkeit des Weglassens erwähnt. Aber einige Projekte haben in ihre Coding-Style-Guides aufgenommen, dass es wegzubleiben hat. Von einem deprecated, im Sinne davon, dass es irgendwann abgeschafft wird, ist nirgends die Rede.

Gilt dies für alle Dateien (rufende und gerufene)?

Eine solche Unterscheidung gibt es seitens PHP nicht.

dedlfix.