nicht angemeldet
Erstmal danke, Phillip für die langen Erläuterungen. Bei (für einen selber) schwierigen Problemen hilft's doch oft wenn man mal darüber geredet hat ;-)
Ich glaube, dass dir die Lösung über AUTOLOAD einfach nicht so gut
gefällt :-) und ich verstehe das (AUTOLOAD ist böse :-)).
Als Resumee, scheint's aber letztlich die Lösung für mich zu sein.
Und je länger ich jetzt damit arbeite umso besser gefällt es mir.
So in etwa sieht es momentan aus:
http://www.uni-mainz.de/~struebig/test/myObj.txt
Es hilft mir beim meiner Schludrigkeit Fehler zu vermeiden, ich krieg immer schön eine Fehlermeldung, wenn ich versuche ein nicht definiertes Feld zu schreiben oder lesen.
Mit anderen Worten: Wenn es zu lästig ist, für jeden Datentyp (z.B.
Tabelle in einer Datenbank) ein eigenes Modul anzufertigen, dann
musst du dir einfach die Vorteile einreden und dich des Resultats
ergötzen :-)
so sieht's aus ;-)
Wäre z.B. folgendes nicht sehr schön (zwar aufwendig, aber schön):?
wie gesagt ich bin relativ schludrig, d.h. ich baue gerne in der Entwicklungsphase DB Objekte um, füge Felder ein und so weiter. Insofern wäre schön zwar schön, ist aber leider nicht mein Stil.
DataAbstraction.pm übernimmt die ganze Datenhaltung, erstellt, löscht
und liest/schreibt alle Daten aus der Datenbank. "Darübergestülpt"
sind alle spezifischen Datentypen, wie z.B. Termin und User. Diese
haben nun fixe Felder und diese können bereits zur Compile-Time ganz
am Anfang festgelegt werden.
Was ich vorher mit "wo kein Bedüfnis ist, kann man sich eines
schaffen" meinte ist, dass jetzt nicht nur auf die Daten über
Class::Accessor zugegriffen werden kann, sondern auch die ganze
Funktionalität (neuer User zufügen, neuen Termin anhängen, Termine
selektieren etc.) in diesen spezifischen Datentypklassen abgelegt
ist. _Das_ halte ich für sehr ästhetisch und dann nehme ich auch
gerne den Mehraufwand in Kauf, für alle Datentypen (User, Termin)
die Felder explizit anzugeben und für jeden Datentypen eine Klasse
anzulegen.
Im grossen und ganzen mach ich es auch so, bis auf die von mir gewünschte Flexibilität von DataAbstraction und den immer wieder benötigten Funktionen.
Ich versuche es nochmals:
Class::Accessor - auch wenn es nicht so aussieht - arbeitet immer
auf Klassen-/Packetebene, das hat perlinterne Gründe und diese kannst
du nicht einfach so in den Wind schlagen; da Class::Accessor mit der
Methoden in der Symboltabelle arbeitet und damit im Kontext
des Packetes arbeitet und nicht im Kontext einer Instanz einer
Klasse (Objekt).Es gibt nur eine Möglichkeit, eine Methode im "Objekt-Kontext" zu
definieren und diese wird dich wohl kaum glücklich machen...:
also kein Wunder dass ich es nicht geschafft hatte, aber so hab wenigstens einen kleinen Einblick in die tiefen von Perl bekommen. Vor allem habe ich dadurch - zumindest ein bisschen - closures verstanden.
Hm, schade wa? - Finde ich eigentlich auch... Obwohl, naja, es ist
sauberer so wie es ist. Instanzmethoden gibt es nicht und somit auch
die Möglichkeit nicht, in Perl $a->field variabel zu gestalten (es
sei denn mit den bereits genannten "Tricks" [AUTOLOAD])
Im Prinzip ist AUTLOAD ja auch ok, ich muss halt nur aufpassen, dass ich das Objekt nicht für Daten benutzte die in grosser Zahl verwendet werden.
Aber selbst unter ungünstigen Umstände wo z.b. ein Objekt 100 mal vorhanden ist und jeweils 10 Eigenschaften abgefragt sollte der Zeitverlust vertretbar sein.
Struppi.