OOP, statische Methoden, Namespaces, funktionale Programm. (JS)

[jobo]

Hallo,

gibt es einen "Missbrauch" von statischen Funktionen (Klasse mit nur statischen Funktionen)? Oder ist das ein Notbehelf, weil es bis PHP 5.3 keine Namespaces gab? Sind statische Funktionen, wenn sie keine Instanz eines Objektes selbst erzeugen, keine Funktionen, die in eine Klasse gehören, sondern ab 5.3 in einen Namespace? Warum wurde das so spät noch hinzugefügt, oder ist das gar nicht "spät"?

Abgesehen davon: was kann PHP nicht, was mit LISP McCarthy "entdeckte" und unter anderem ja wohl mit "Funktionaler Programmierung" bezeichnet wird. Wobei das - und die Rekursion leitet sich wohl davon ab - daran läge, dass Funktionen Objekte erster Klasse wären, die auch als Parameter übergeben werden können. PHP kennt ja auch call_user_func.  Und eval, was bei Paul Graham ja als kleine Revolution dargestellt wird, Code, der selbst Code erzeugen kann! Das hat mir ein Entwickler auch schon von Ruby erzählt und Crockford lässt sich über Lisp und Javascript aus ("Javascript is Lisp in Cs clothing" heißt es ja wohl).

Was lässt sich demnach von PHP auf Javascript übertragen (konzeptionell) und was nicht?

Gruß

jobo

[mrjerk]

Hallo,

gibt es einen "Missbrauch" von statischen Funktionen (Klasse mit nur statischen Funktionen)? Oder ist das ein Notbehelf, weil es bis PHP 5.3 keine Namespaces gab?

Es war sicher auch ein Notbehelf, als Missbrauch würde ich es aber nicht sehen. Auch in Sprachen, in denen Namespaces von Anfang an vorgesehen waren, kann man Klassen nur aus statischen Methoden bauen.

Ob man solche Methoden in eine Klasse oder einen Namespace auslagert, liegt IMO in der Freiheit des Entwicklers, und hat auch immer etwas damit zu tun, welchen semantischen Zusammenhang er zwischen Funktionen ausdrücken möchte.

PHP kennt ja auch call_user_func.  Und eval, was bei Paul Graham ja als kleine Revolution dargestellt wird, Code, der selbst Code erzeugen kann!

Ich sehe da schon nochmal einen Unterschied:
In LISP/JavaScript/Ruby/Perl/... wird tatsächlich eine Referenz auf die auszuführende Funktion übergeben. Die von Dir angesprochenen Konstrukte hingegen benutzen die Funktions-Namen als Refrenzen. Damit kann zwar in vielen Fällen etwas ähnliches konstruiert werden, es ist aber technisch nicht dasselbe.

Die in PHP 5.3. eingeführten Konstrukte erlauben allerdings nun auch das Erstellen von Funktionen a la LISP, sowie Closures.
Damit ist man tatsächlich was das betrifft LISP sehr nahe gekommen.

Was lässt sich demnach von PHP auf Javascript übertragen (konzeptionell) und was nicht?

Ich weiß nicht, ob man das sinnvoll gegenüber stellen kann.
In JavaScript ist alles ein Objekt - Funktionen, Variablen, Zeichenketten, alles! JavaScript selbst besteht aus nicht viel mehr als aus ein paar sehr primitiven Basis-Objekten. Alles weitere (Vererbung, "Klassen",...)  ergbibt sich immer als Erweiterung dieser Basis-Objekte.
Dies ist das Kernparadigma von JavaScript, dass es so in PHP nie gab (und ich glaube, bis heute nicht gibt).

PHP andererseits ist historisch gesehen ein Toolkit für Webseiten gewesen (Personal Homepage Tools) - in seinem Ursprung war es nicht als komplexe Programmiersprache gedacht gewesen, sondern als Skript-Sammlung. Objektorientierung uva. wurde erst nachträglich eingebaut, als man gemerkt hat, wieviele Leute damit große Anwendungen entwickeln wollen.
Dies merkt man PHP bis heute an, auch wenn es inzwischen in seinem Sprachumfang klassichen Sprachen in nichts nachsteht.

Konzeptionell kann man deswegen IMO schon deshalb beide nicht miteinander vergleichen, weil sie sich mit völlig unterschiedlichem Fokus entwickelt haben.

These were my 5 cents...

Jörg