[linux-l] ein biscchen offtopic: php Frage

Steffen Dettmer steffen at dett.de
Sa Nov 23 17:41:49 CET 2002


* Guntram Trebs wrote on Sat, Nov 23, 2002 at 13:42 +0100:
> On Sat, 23 Nov 2002, Steffen Dettmer wrote:
> > Was ist mit Objekten? Sowas gibt's doch in PHP?
> 
> $a = 1;
> $a = new foo();

> ist korrekter Code, die Variable $a hat keinen Typen, nur der Wert der
> Variable hat zu jedem Zeitpunkt einen bestimmten Typen, einen Integer,
> einen String, ein Array oder eine Klasse.

Yep, also wie in Perl. 

> Das hat ja manchmal Vorteile, oft will man aber eh nur einen
> bestimmten Typen haben und um Fehler zu vermeiden diesen
> festlegen. Das geht leider nicht.

In Perl kann man sich sowas notfalls nachbauen, geht in PHP
bestimmt auch, aber ist umständlich und macht man daher meistens
nicht :)

> Zahlen gemacht. (eigentlich sollte man Strings dafür verwenden)

Besser Klassen.

> <?PHP
> $x = 0179;
> echo $x;
> ?>
> 
> hat dann 15 ausgegeben. 

Perl, Java und C merken das.

> Eigentlich hätte PHP an der Stelle sogar einen Syntax-Fehler wegen
> der 9 melden müssen, man kann ja auch nicht $x = 12z; schreiben.

Ja, das ist falsches Verhalten. 0179 ist keine Zahl, es kann dann
also nur ein Fehler oder ein String sein. Na ja, PHP hat verdammt
viele kleinere solcher Probleme, aber da kennst Du Dich sicher
besser aus, als ich :)

> Wer seine Scripte möglichst korrekt schreiben möchte, sollte am Anfang
> <?PHP
> error_reporting(E_ALL);
> ?>
> verwenden. Aber Vorsicht, viele Websites dürften danach nicht mehr
> wiederzuerkennen sein, vor lauter Fehlermeldungen.

Embedded HTML verwendet vermutlich eh keiner für sinnvolle
Websites, und bei Spielereien sind die Fehler ja auch egal. Ist's
eben weniger bunt.

> Ich mach das neuerdings so, daß ich beim Testen E_ALL einschalte und
> online dann error_reporting(0) setze, teilweise sogar dynamisch, sprich
> wenn ich selber drübersurfe ist es gesetzt, bei allen anderen nicht.

Ach ja, PHP ist ja auch noch so CooL, dem Hacker die
Fehlermeldung defaultmäßig genau anzuzeigen, so nach dem Motto

error connecting oracle database 1.2.3.4, username "web",
passwort "secret": connection refused

Das ist wirklich genau das, was ich von einer Webanwendung nie
sehen möchte.

> Das hat sich schon ausgezahlt, da ich Fehler gefunden haben,
> die ich sonst nie entdeckt hätte.

Ich hab es meistens am liebsten, wenn im Fehlerfall mit viel
Logmeldungen abgebrochen wird, und dem User eine generische
Fehlermeldung präsentiert wird. Der Rest steht dann im Logfile.

> > Doch, meine Frage hast Du sehr ausführlich und interessant
> > beantwortet, danke!
> 
> Na gut, hatte schon befürchtet, das läuft wieder auf so eine Perl ist
> besser als PHP-Diskussion heraus.

:) Was soll man da diskutieren, ist doch klar! :) SCNR.

Nee, es gibt auch embedded Perl, da mischt man dann auch HTML und
Perl, und ich bin mir ziemlich sicher, da kommt auch nix bei
raus. Das hat mehr was mit Programmiertechniken zu tun als mit
Sprachen. Man kann fast jede Sprache mißbrauchen...

> Daß PHP noch in den Kinderschuhen steckt, ist mir klar, ich bin
> da auch schon verzweifelt an einigen Bugs und
> Kinderkrankheiten.

Na ja, ich finde, der Weg ist falsch. Die Grundsprache ist
unsauber designed, insbesondere das sogenannte
"Sicherheitskonzept" ist keines, dafür gibt es aber Millionen von
Bibliotheksfunktionen, die fest eincompiliert sind. Das sollte
man lieber modular machen, wie bei den anderen Sprachen. So muß
man ja ständig PHP updaten, und wenn man es selbst kompilieren
möchte, muß man sich die Millionen von Bibliotheken in der
allerneuesten Beta-Version installieren. Das kann nicht
funktionieren. Und ich bin auch der Meinung, daß der Stil der
Zend Engine schlecht ist, weil absolut unverständlich und
kryptisch. Ich hab das mal debugged, es ist wirklich grausam.
Deshalb ist es vermutlich auch so ein Problem, Bugs da
rauszumachen. Es kann bei PHP passieren, daß 

$a="";
$b="abc";
$c = $a+$b; 

(weiß nicht sicher, ob "+" der string-concat Operator ist)
fehlschlägt. Ich hab mal ein assert in die
String-Konkatenierungsfunktion gemacht, manchmal sind die strings
nämlich NULL, aber 1249871624 Zeichen lang oder sowas...

> Perspektivisch werde ich wohl versuchen, auf serverseitiges Java
> umzustellen. Hab da aber noch nicht viel Erfahrungen. 

Da gibt's dann wieder ganz andere Fallen. Aber halte ich für die
bessere Lösung, wenn auch meistens oversized ohne Ende. Aber wenn
echtes CGI zu klein ist, dann lieber einen Catalina Server, finde
ich (hab da aber auch keine Erfahrungen, hab nur JavaSwing
Clientseitig und richtige Server gemacht - wo ich leider
Speicherlöcher habe :( na egal).

> Aber ich hoffe mal, daß dann viel weniger Fehler im Code sind,

Der Java-Compiler ist nicht annähernd so schlecht wie der PHP
Compiler, klar. Java finde ich fast so gut, wie C++, gerade für
GUIs absolut geeignet (nur auch nicht super schnell).

> die Komponenten besser wiederverwendet werden können und
> schneller entwickelt werden können. Die OO-Unterstützung von
> PHP reicht mir nicht.

Das sehe ich genauso. Das ist in Java wirklich gut gelöst, auch
das Class Loading und der Kram. Es ist wirklich einfach, man muß
nur aufpassen, es nicht zu einfach zu machen. Wenn man sich um zu
wenig kümmert, weil Threads ja zu einfach sind, kann einem das
auch sehr schnell auf die Füße fallen. Ein Kollege von mir hatte
da gerade massive Probleme...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l