http://www.cpan.org

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...


----
[{Tag Perl Templates}]