[quote=Strazke,13.09.2005, 23:27]Ok, hier verstehe ich nicht, wozu man überhaupt einen Konstruktor braucht. Ist es nicht viel einfacher, einfach eine Funktion zu schreiben, die das gewünschte zurüchgibt? Und mal sehen ob ich das richtig verstanden habe: Es wird ein Hash erstellt, das dann Tree zugeordnet wird(wieso das eigentlich?) und dann wird es zurückgegeben.

Stimmt das so weit?[/quote]
man verwendet normalerweise einen konstruktor, um ein neues objekt zu erzeugen (ok, geht auch ohne, aber meistens ist es sauberer, einen zu benutzen).
Als Basis fuer ein Objekt muss man eine Referenz verwenden (man verwendet dafuer meistens eine hashreferenz, und der Name $self hat sich in Perl eingebuergert. Diese Referenz wird erst durch bless($self, $type) zu einem Objekt (d.h. in Perl: zu einer Referenz, die weiss, in welche[s]n Namensraum[/s] Klasse sie gehoert).
Das hat den Vorteil, dass man dann schreiben kann: $object->methode(...) und dann ueber das Objekt ermittelt werden kann, um was fuer eine subroutine es sich genau handelt. ok, man koennte zwar sowas auch manuell machen, indem man z.B. Class::methode($hashRef, ...) aufruft, aber das wird, wenn man vererbung benuetzt, um nicht jede funktionalitaet in jeder klasse nochmal coden zu muessen. Und der Weg des Methodenaufrufes macht das ganze einfacher zu handeln, weil man nur beim aufruf des konstruktors ueber den Namen der Klasse bescheid wissen muss, und sich dann um das dahinterliegende nicht mehr zu kuemmern braucht.

Durch OOP ist es bei der DB-Programmierung viel einfacher, mehrere datenbankverbindungen gleichzeitig zu handeln, oder mehrere sql-abfragen zur gleichen zeit abzufeuern (z.B. man liest in einer hauptschleife irgendwelche daten aus, und bei jedem schleifendurchlauf (d.h. fuer jede zeile) fuehrt man fuer die gefundenen daten irgendwelche anderen statements aus).

Sowas koennte man auch ohne OOP realisieren, aber die verwendung ist selten so komfortabel...

Der Hauptvorteil von OOP ist, dass Daten und die Methoden, ueber die auf diese Daten zugegriffen wird, gemeinsam (in einer Klasse) gespeichert werden, und dass dem benutzer dieser Klasse idealerweise voellig verborgen bleibt, auf welcher datenstruktur diese Daten abgebildet sind. Wenn man die Funktionalitaet einer Klasse erweitern will, kann man einfach eine neue Klasse von dieser klasse ableiten, und man muss nur die Erweiterungen coden, nicht jedoch den gesammten rest.

@J-jayz-Z
Was bringt in deinem Code :
1. die =head Teile
2. die Frage zeichen bei sub new

Danke

=head ist ne POD anweisung also dokumentation(kommentar) und das hat nichts mit dem programm an sich zu tun

Mit den Fragezeichen meinst du die Dollars($) ?
Wenn ja, schau dir mal perldoc perlsub an. Die stehen für die Werte, die der sub übergeben werden sollen

Für POD siehe:
http://perl-tutor.de/cgi-bin/perl_pod.pl\n\n

<!--EDIT|J-jayz-Z|1126708169-->

Noch eine Frage: Muss man in dem Package nicht irgendwas wie
sub Foo::INC {
my ($self, $filename) = @_;
...
}

machen, damit man es benutzen kann? oder kann man auch irgendwie den direkten Pfad angeben?

hmm, wie kommst du auf Foo::INC ?
Also das Modul läuft, so wie es da steht. Es gibt zwar noch etwas, das nennt sich Exporter und nochwas, das das @ISA Array verwendet, aber man muss es nicht verwenden. zumindest nicht in diesem Modul

@ISA : Eine Liste, in der drin steht, von welcher Klasse geerbt werden soll

EXPORTER: zum exportieren von Funktionen(Methoden)\n\n

<!--EDIT|J-jayz-Z|1126715875-->

und wie kann ich es dann verwenden?

das und andere methoden funktioniert nicht:
use 'mysql_easy';

Wenn du es in einem der Pfade von @INC gesichert hast (perl -le 'print for @INC') kannst du es so nutzen. Sonst muss du es mit require "/pfad/zu/mysql_easy.pm"; einbinden !

EDIT: use mysql_easy; reicht. Lass die Anführungsstriche weg !\n\n

<!--EDIT|J-jayz-Z|1126716037-->

[quote=J-jayz-Z,14.09.2005, 16:28]Mit den Fragezeichen meinst du die Dollars($) ?
Wenn ja, schau dir mal perldoc perlsub an. Die stehen für die Werte, die der sub übergeben werden sollen[/quote]
aber die "dollars" (der "prototyp") sind hier überflüssig. manche verwenden sie gern zur
dokumetation auch in OO, aber ich finde das eher verwirrend, denn
man bekommt halt keine fehlermeldung, wenn man die werte falsch übergibt,
und somit ist es wahrscheinlich, dass der prototyp irgendwann veraltet ist
und nicht mehr stimmt.