Vom 8.-13.6.2001 habe ich eine Untersuchung über die verschiedenen Klassen im CPAN durchgeführt, die sich mit Klassentemplates beschäftigen.
Class::Translucent attribute translucency: Die Objekt-Attribute haben globale Default-Werte. Ist ein Wert nicht gesetzt, wird der Klassen-Default genommen. Interessante Idee.
Tangram Tangram beschäftigt sich damit, Perl-Datenstrukturen in SQL-Datenbanken abzubilden. Das ganze scheint recht umfangreich zu sein. Daher scheidet wohl eine Modifikation/Integration aus. Das Haupt-Augenmerk scheint darauf zu liegen, verschiedene Perl-Datentypen jeweils abbilden zu können.
Ich stelle mir allerdings eher vor, nur noch einen Datentyp zu haben und die Komplexität dahinter zu verbergen.
Vielleicht kann man hier mal nachschlagen, wenn man Lösungen für einzelne Probleme mit vertrackten Datenstrukturen sucht.
Persistent::Base Hochinteressantes Modul. Sehr einfach können Datenbanken definiert werden und dann einzelne Objekte und/oder Attribute bearbeitet werden.
- Drei Arten von Attributen: Identity (Schlässelfelder), Persistent und Transient(nicht abgespeichert)
- ->data-Funktion ergibt einen normalen Hash. Gute Idee!
- ->datastore-Funktion ändert die "Ablagestelle" eines Objektes.
- restore(), insert() und update() zur Synchronisation mit der Datenbank
Alles in allem ein sehr guter Ansatz für Objektpersistenz, aber vielleicht nicht für die anderen Klassen-Faxen, die ich brauche. Vielleicht kann man das aber für die Persistenz in Datenbanken brauchen.
Class::Template Kurz und prägnant - so liebe ich Perl. Ich schreibe ein struct-Statement, hinter dem ich kurz die Attribute schreibe und danach habe ich eine fertige Klasse, die ich nur noch benutzen muss.
So muss die Minimal-Anwendung meiner Klasse aussehen!
Class::MethodMaker Dient zum Erstellen von Accessoren. Vom Ansatz her gefällt mir schon an der Doku, daß nicht so sehr abstrahiert wird. Es wird nicht gesagt "wir erzeugen hier ein Objekt und greifen mit diesen und diesen Funktionen darauf zu", sondern es sagt "Wir erzeugen ein paar Methoden, die tun dann das und das". Interessant, wie die Funktionsweise dieses Moduls mir direkt eingänglicher ist als andere, denen ich irgendwie nicht richtig über den Weg traue. Ich sollte mir das merken...
Interessant: Ich kann ein Attribut als Objekt definieren. Dann kann ich Objektmethoden angeben, die als meine eigenen Methoden eingerichtet werden, die dann Ihren Aufruf 'durchreichen'. Gute Idee!
Als Feldtypen in den "Slots" gibt es auch Objekte, Listen, Hashes, etc. Sieht recht vollständig aus.
Class::Fields Fields hat was mit dem 'use fields'-Mechanismus von Perl zu tun (siehe perldoc fields). Elemente eines Hashs können private für seine Klasse gemacht werden etc.
Das hat nicht viel damit zu tun, was ich will. Meine Daten werden eh nicht zwingend in einem Hash abgelegt und private Sachen gibts nicht. Damit nähere ich mich für meinen Geschmack zu sehr den Problemen von C++ an.
Class::DBI abgeleitet von Class:Accessor
Dieses Modul versucht eigentlich nur, DBI und alle SQL-Befehle hinter Perl-Funktionen zu verstecken. Man kann also im Grunde alles wesentliche machen, was mit DBI so sinnvoll ist und braucht seine Hashes nicht selber in SQL-Befehle hineinzudröseln.
Ich weiss nicht, ob man das verwenden kann, sonst taugt es vielleicht als Beispiel, wie man die richtigen SQL-Befehle schreibt.
Die Acessor-Methoden können im manual commit oder autocommit Modus sein. (entsprechend gibt es eine commit- und eine rollback-Methode) Gute Idee!
Class::Contract Ein hochinteressanter Ansatz. In einer Definitionsstruktur werden Attribute, Methode, Konstruktoren etc. definiert. Ausserdem können Bedingungen erstellt werden, die z.B. vor oder nach den Methoden aufgerufen werden. Sind diese Bedingungen nicht erfüllt, gibts eine Exception.
Ob man diese Bedingungssache braucht, weiss ich nicht genau. Das Problem ist, dass diese extra geschrieben werden. Man muss also für jede Killefitz-Methode eine Killefitz-Testroutine schreiben und macht dann garantiert denselben Fehler nochmal. Also bringts nix. Eine Idee wäre allerdings sowas wie eine ok()-Funktion, die von allen Methoden (vorher und nachher?) aufgerufen wird.
Es gibt eine Extra-Production-Version der Klasse, die die vielen checks weglässt und dadurch performanter ist. Gute Idee!
Die Deefinitionsstruktur fasst die Attribute und Methoden in einen Block ein (letztlich ein Hash). Allerdings könnte man IMHO per Makros oder so auch später nachgeschobene Methoden einbinden. Der Vorteil von dem Ansatz ist, daß man Definition und Implementation nicht trennt, aber doch beides hat.
Class::Accessor Diese Funktion baut aus einer kurzen Klassenbeschreibung accessor-Funktionen zusammen.
Diese sind übrigens als Closures implementeirt, was zwar beim Aufruf etwas umständlicher ist, aber dazu führt, daß nicht für jedes Attribut eine eigene Funktion erzeugt wird.
Fazit: An sich eine sehr Klasse. Der Closure-Ansatz ist mir nicht performant genug bis in die letzte Konsequenz. Aber vielleicht kann man ja damit erstmal anfangen. Ändern kann man später immert noch?!? Andererseits kann ich auch mit dem anfangen, was ich bis jetzt habe. Schlecht ist das ja auch nicht...