hi Tom,
das scheint ja langsam ein philosophisches oder archäoligisches Problem zu werden. Graben wir doch mal in den Bits.
Gerne. Aber eines vorweg: Das 'P' in Perl steht für Praxis und so halte ich das auch, ich bin ein Praktiker. Es stört mich nicht im Geringsten, wenn böse Zungen behaupten, dass Perl überhaupt kein OOP kann. Ich programmiere nicht der OOP willen, sondern um Aufgaben zu lösen.
Meiner Meinung nach könnte es so zusammenhängen:
Eine Klasse ist nur ein Baumuster. Das liegt statisch vor, wenn das Programm läuft. Nun wird eine neue Instanz angefordert. Das geschieht durch
newinstance = new(baumuster);
Was passiert hier?
Ich sag mal so: es kommt darauf an, nämlich ob es ein generisches Klassensystem (C++), ein typisierendes Klassensystem (Delphi) oder ein Interpretersystem (z.B. PHP) ist. Was in allen aber gleich ist:es wird Speicherplatz für die Klassenvariable allokiert, egal, wieviel daws jetzt ist.
Darüberhinaus wird i.a. auch Speicherplatz für die statischen Teile der Klasse allokiert
und diese werden dort hineinkopiert. Das sind einfache Variablen und z.B. die Adressen zu
den Methoden.Damit ist die (Kern-)Instanz gebildet, noch bevor irgendwelche Initialisierungen stattgefunden haben, mit Ausnahem der statischen Werte. Die stehen jetzt bereits hardcoded im Speicher.
Siehst Du, da ist einiges im Argen. Aus dem Source aller Methoden der Klasse wird CODE erzeugt, der im Speicher rumliegt. Es werden jedoch nicht immer alle Methoden gebraucht. Außerdem kostet das Compilieren Zeit. Wie wärs damit, den Code erst zu erzeugen, wenn die Methode gebraucht wird? In Perl geht das prima zu machen, dafür gibts AutoLoader, SelfLoader.
Zugegeben, so manches Verfahren wirkt in Perl einwenig verstaubt und meine Module/Scripts erwecken mitunter den Anschein eines fossilen Charakters ;) Aber sie erfüllen ihre Bestimmung plattformunabhängig ung abwärtskompatibel bis zu einer Perl-Version, die es seit 2001 gibt.
Z.B. bin ich seit gestern dran, den AutoLoader so einzusetzen, dass Methoden, welche nicht immer gebraucht werden (Content-Management...) als Source aus einem Hash geladen werden, welcher über eine TIE-Klasse an eine Binär-Datei gebunden ist. Ein Bench, der Vergleich, zehntausend (!) Klassenmethoden auf einmal zu kompilieren um dann nur eine auszuführen, viel erwartungsgemäß um Längen schlechter aus, als eben nur das Compilieren der einen verlangten Methode. Wobei meine TIE-Klasse nicht die komplette Datei in den Hauptspeicher lädt, sondern nur den Index mit Offsetangaben zur Binary, somit wird auch erst auf Anforderung die Source der Methode in den RAM geladen.
und jetzt kommt die Philosophie
für standadisierte dynamische Teile der Klasse könnte bereits jetzt Speicherplatz allokiert
werden, aber vielleicht auch erst dann, wenn er tatsächlich angefordert wird von der Klasse
Was heißt 'könnte'!?, machen! Siehe oben ;)
Damit ist aber klar, der Konstruktor war noch gar nicht tätig. Dieser kann nämlich erst ins Spiel kommen, wenn er selber abgebildet worden ist, entweder durch Codekopie, oder durch Referenz auf den Standardkonstruktor.
Mein Konstruktor heißt TIEHASH und der war bis hierhin sehr wohl schon unverschämt aktiv ;)
Wenn jetzt als nächstes die Kontrolle an den Konstruktor übergeben wird, kann er für neue Speicherall0kation sorgen und diese Fragmente innerhalb der statisch vorbereiteten Teile der Instanz eintragen.
Nein. Mein Konstruktor hat ferig, der kriegt nichts mehr übergeben.
Ich mag OOP-Programmierung nicht, weil alle Systeme es "innen drin" anders machen.
Programmiere nicht der OOP Willen.
Das große Problem ist jetzt nur, dass man wissen muss, welches System dem anderen (teilweise) zugrunde liegt. PHP ist nunmal in C programmier und das hat auch schon ein paar Eigenarten.
Kein Problem, Perl ist auch in c geschrieben. Wenn ich in c Speicher allociere, muss ich die Länge und den Datentyp angeben, dann kriege ich einen Zeiger auf die Speicheradresse. Perl allociert selbst den Speicher, in dem Moment, wo eine Variable ins Leben gerufen wird. Erst dann kann ich eine Referenz erzeugen, welche auf den Speicherplatz zeigt, aber auf diese Referenz kann ich in Perl später alles Mögliche schreiben (was in c nicht zu machen ist) und ich kann es mir aussuchen, ob ich eine neue Variable ins Leben rufe oder in einer bestehenden Referenz weitere Referenzen hinterlege.
Perl-Praxis: Die Instanz einer Klasse ist eine Referenz. Attribute sind nichts Anderes als Namen für weitere Referenzen. Attribute können auch Instanzen fremder Klassen sein, deren Methoden entweder geerbt oder delegiert werden.
So! Nun haben wir genügend Stoff, damit sich auch noch ein paar Andere über uns hermachen können :-)
Lass die nur machen. Im Gegenzug dürfen auch wir uns über die Anderen lustig machen, heimlich oder offen. Allein die Namen der in PHP unzähligen Built-In-Funktionen haben mit schon so manches Schmunzeln abgerungen ;)
void gaeste_buch_mysql(firstname, lastname, email, subject, dbh, charset, message, link, link_title, link_descr);
Hotti