Module, die sich als Eierlegende-Wollmilch-Sau geben, haben oft ein Problem: sie können zu viel und irgendwie nichts richtig. Das Gefühl hab ich beim CGI-Modul schon lange. Und heute wurde es auch bewiesen. Ich habe mir leider nie die Mühe gemacht in die CPAN-Bugliste vom CGI-Modul zu sehen. Hätte ich’s man bloß getan.

Insgesamt sind derzeit 115 Fehler gemeldet, einige davon schon seit Jahren. Live erlebt habe ich den folgenden Fehler in der url() Methode. Ungequotet wird der Scriptname in eien Regex gesetzt. Unter mod_perl ist dummerweise der Scriptname der gesamte Pfad. Ein [ im Pfad der URL führt zu einem Laufzeitfehler, wenn man diese Funktion in der Anwendung benutzt.

Ende vom Lied: ich werde mich wohl mal nach einer Alternative umsehen, die sich AUSSCHLIEßLICH um die Entgegenname von Parametern kümmert und noch ein zweites für die Ausgabe von HTTP-Headern.

Bei den CPAN-Tests für das Fukurama::Class Modul sind mir zwei Dinge aufgefallen, die auf unterschiedlichen Systemen unterschiedlich von Perl behandelt werden:

1. Zahlenüberläufe werden unterschiedlich markiert. Ich kenne inf, Solaris z.B. benutzt aber Infinity und einige andere hatten noch ein Inf am Start (großgeschrieben). Das fällt nie auf, auer man behandelt genau diese Überläufe.

2. Klassennamen können nicht immer als Parameter übergeben werden. Ich hatte im Test ein $obj->param(My::Class) verwendet. Das schlug aber komplett fehl. Ich musste es als String übergeben ala $obj->param(‘My::Class’). Nicht weiter tragisch, sofern man es denn weiß. PS: Für __PACKAGE__ gilt das natürlich auch.

Soeben ist ein CPAN-Tester mit einer Windows-Gurke über meine Tests gelaufen. Ich weiß, daß in Visual-Basic z.B. die Boolische Werte in der Landessprache geschrieben werden können. Wie z.B. “true”, “wahr” oder “vrai”. Bei Perl haben sie sich auch Mühe gegeben: -1.#IND für NaN und 1.#INF für Inf. Toll!

In dem Modul erzwinge ich jetzt einen Überlauf und suche mir halt die Systemeigenen Werte. Hmpfrl!

Aufgrund meiner Recherche über PerlXS & co. bin ich im CPAN über das Modul Inline gestolpert. Ich hab es zwar noch nicht genutzt, aber wenn es so funktioniert wie beschrieben, könnte man theoretisch eine Anwendung aus vielen Teilen zusammensetzen, in auch noch in verschiedenen Sprachen geschrieben wurden.

Das hat meiner Meinung nach einen Vorteil, vorausgesetzt man setzt es mit Bedacht ein: Jeder Programmteil kann in der Sprache geschrieben werden, die am besten geeignet ist. Da es aber nur wie eine Art Kleber die Programmteile zusammenfügen kann, ist das wohl nicht ganz so einfach. Denn vom Java-Code aus dann über Perl auf C++ Code zuzugreifen könnte eine echte Herausforderung sein. Vor allem, da im Hintergrund ja ständig Konvertierungen laufen dürften.

Ich werd mal ein wenig damit spielen aber ich fürchte, es wird auch in der Perl::Kinky-Ecke verbleiben.

Ich bin heute Morgen über ein interessantes CPAN-Perl-Modul gestolpert: Internals. Das bietet die Möglichkeit, einen Hash zu schützen, so dass niemand mehr den Inhalt verändern kann.

Die Warnungen am Ende des Modules lassen vermuten, dass man damit direkt in den Perl-Eingeweiden rumwurschtelt. Da ich PerlXS jetzt sowieso angehen will, hab ich mir vorgenommen, das Modul mal auseinander zu nehmen. Mal sehen, was man damit so alles anstellen kann. *Muahahahahhaa Muahahahahahaha!*

In der POD perldoc perlop gibt es folgenden Kommentar zum while {} continue {} Konstrukt.

This usage is vaguely deprecated, which means it just might
possibly be removed in some distant future version of Perl,
perhaps somewhere around the year 2168.

Jetzt wissen wir, wann Perl6 kommt: Weinachten 2168!