[php] Re: java vs. php

[Daniel Lorch]

hi,

> Das wiederum interessiert mich überhaupt nicht (in einer Skriptsprache). 
> Schau mal auf die jüngsten Umfragen unter PHP-Anwendern: das Gros der 
> PHP-Anwendungen ist sehr klein (< 20kloc) und wird in kleinen Teams (< 3 
> Developer) entwickelt.
> 
> Bei so kleinen Anwendungen kann man recht schnell alles neu schreiben.

Ja, man kann argumentieren, dass PHP Arbeitsstellen schafft oder 
erhaelt. Insofern gute Sache ;) Refactoring ist immer noetig um neuen
Beduerfnissen gerecht zu werden, aber ein komplettes Rewriting ist
ziemlich doof - besonders dann, wenn es keinen Zusatznutzen bringt,
sondern nur darum geht einer neuen API gerecht zu werden.

Schau, fuer viele Einsatzgebiete ist es Overkill seine Web-Applikation 
zu layern und mit hunderten Abstraktionslayern (die auch zuerst erlernst 
werden muessen) zu versehen, aber in vielen Faellen macht es eben doch
Sinn. Und da muss man abwaegen.

> PHP hat sich gegen Standards entschieden. Es gibt nichts, was Du einmal 
> lernen kann und dann dein Leben lang benutzen kannst. PHP ist im Fluß, 
> keine Chance sich auf die faule Haut zu legen.

Ich find es toll, dass mein PHP-Wissen mit einem Verfallsdatum versehen
ist. Klar ist es nicht schwierig sich wieder neues Wissen anzueignen,
aber ich will doch, dass mein Fundament erhalten bleibt und nicht unter
meinen Fuessen wegbroeckelt.

>> Die Wohldefiniertheit dieser Abstraktionen ist nicht spezifisch zu
>> Java, aber dort wird sie (mehr oder minder) konsequent eingehalten.
> 
> Hmm, Java und GUI-Zeugs...

Hmm, PHP und GTK-Zeugs...

> Wozu brauche ich eine Datenbankabstraktion? Datenbankabstraktionen sind 
> Blödsinn. Entweder ich gehe gleich auf DAO's oder ich laufe doch wieder 
> in die Abhängigkeit von einer (spezifischen) Datenbank. Spätestens beim 
> schreiben des SQL's... Egal. Ich arbeite sei 1998 mit der PHPLib 
> DB-Klasse und bin recht glücklich mit dieser Low-Level-Abstraktion.

Spaetestens wenn Du http://c-jdbc.objectweb.org/ kennengelernt hast,
wirst Du merken, dass es Sinn macht eine Abstraktion zu etablieren.
Selbst wenn man das zu PHP portieren wuerde: Wie koenntest Du das
transparent (ohne Refactoring) in eine bestehende PHP-Applikation
einbinden?

> Die Zend Jungs basteln Bytecode während des Parsings. Das macht die 
> Kompilierung schnell. Es gibt jedoch keinen AST und damit keine 
> nennenswerte Möglichkeit zur Optimierung. Außerdem ist da noch der .NET 
> Gedanke, der CLR: CPAN lockt.

.NET macht nichts Neues. Es gibt Compiler fuer andere Sprachen, die Java
Bytecode erstellen:

   http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

Aber ja, bei Parrot ist das ein Grundgedanke, den ich vergessen hatte.

> Es gibt diverse Formen von Polymorphismus. So beherrscht PHP 
> beispielsweise den Subklassen-Polymorphismus (Inklusions-Polymorphismus) 
> während Methodenoverloading nicht durch die Syntax der Sprache 
> unterstützt wird.

k.A. wie sich das nennt. Bei OO ist es "best practice" Interfaces
(fuer C++ Programmierer: das sind Abstrakte Klassen mit nur
virtuellen Methoden; fuer CORBA-Programmierer: das IDL einer Klasse)
als Argumente von Methoden zu verwenden:

   interface Tier {
     private String name;
     public String getName();
     public void setName(String name);
   }

Eine Klasse, die dieses Interface implementiert:

   class Kuh implements Tier {
     private String name;
     public String getName() {
        return name;
     }
     public void setName(String name) {
        this.name = name;
     }
   }

Und jetzt die Klasse:

   class Metzger {
     public schlachten(Tier tier) {
        // [..]
     }
   }

Die Methode "schlachten" kann jetzt nur Klassen als Argument
nehmen, die das Interface "Tier" implementieren, wie z.B. Kuh.
Keine Ahnung, wie man das nennt, aber da PHP5 nicht typensicher
ist, kann sowas nur runtime gehen. PHP5 fuehrt ja interfaces ein
und ich sehe nicht ganz, wie das gehen soll. Erleuchtende Kommen-
tare, bitte ;)

-daniel