ausserdem wird sichergestellt, dass kein Code ausgeführt werden kann, ist also daher sicherer als Dump oder Storable

Bei .ini files sollte man ja auch einen der genannten Parser verwenden und kein eval...

[quote=renee,08.02.2006, 10:28]Bei .ini files sollte man ja auch einen der genannten Parser verwenden und kein eval...[/quote]
ich bezog das jetzt auf die serialisierung von kompletten Datenstrukturen.

Also ich finde die meisten dieser Serialisierungsformate, die wir Pilze aus dem Boden schießen, total sinnlos.

Meiner Meinung nach sollte man entweder ein ganz einfaches Format nehmen, wie zum Beispiel eine INI-Datei, oder aber, wenn man komplexe Strukturen braucht, sollte man etwas nehmen, was trotzdem halbwegs kompatibel, standardkonform und möglichst generisch ist -- schließlich kann es sein, dass man die Daten aus irgendeinem Grund mal nicht mit dem Programm, für das sie ursprünglich gedacht waren, verarbeiten will.

Es bietet sich da eigentlich fast nur XML an. XML ist zwar schlecht designt, extrem hässlich, speicherineffizient und ich mag es überhaupt nicht -- aber es ist im Moment einfach der Standard. Da gibt es für fast jede noch so exotische Programmiersprache oder Anwendung einen Parser.

In der Welt der Lispdialekte, in der ich mich oft bewege, kann man dann natürlich noch ganz portabel S-Expressions zur Serialisierung nehmen. Kann mehr als XML, ist aber einfacher und speichereffizienter. Keine Ahnung, ob es dafür ein Perlmodul gibt, aber es ist auch (leider) nicht so verbreitet unter Leuten, die kein Scheme, Common Lisp oder ähnliches programmieren.

also ältere YAML-versionen haben bugs, und bei den neuesten versionen
schlagen die tests fehl. außerdem finde ich persönlich das YAML-format
nicht besonders gut lesbar/editierbar.

[quote=murphy,08.02.2006, 11:18]Also ich finde die meisten dieser Serialisierungsformate, die wir Pilze aus dem Boden schießen, total sinnlos.

Meiner Meinung nach sollte man entweder ein ganz einfaches Format nehmen, wie zum Beispiel eine INI-Datei,
[/quote]
Das wäre *keine* Serialisierung, weil man nur einfache Hashes abbilden kann.

Quote

oder aber, wenn man komplexe Strukturen braucht, sollte man etwas nehmen, was trotzdem halbwegs kompatibel, standardkonform und möglichst generisch ist -- schließlich kann es sein, dass man die Daten aus irgendeinem Grund mal nicht mit dem Programm, für das sie ursprünglich gedacht waren, verarbeiten will.

Leider gibt es da zwei Marschrichtungen: man will es besonders schnell haben und legt nicht auf Menschenlesbarkeit Wert, dann nimmt man Storable. Oder man will es menschenlesbar haben, dann nimmt man Data::Dumper. Leider muss man hier beim Rückumwandeln eval() verwenden --- nicht sehr sicher. Auch sind manche Leute der Meinung, dass Perl nicht so lesbar ist wie, sagen wir mal, YAML. Und Perl ist nicht portabel. Auch deshalb gibt es YAML.

Quote

Es bietet sich da eigentlich fast nur XML an. XML ist zwar schlecht designt, extrem hässlich, speicherineffizient und ich mag es überhaupt nicht -- aber es ist im Moment einfach der Standard. Da gibt es für fast jede noch so exotische Programmiersprache oder Anwendung einen Parser.

Das Problem ist: man kann Perl-Datenstrukturen nicht 1:1 nach XML und umgekehrt umwandeln. OK, man kann schon, aber dann sehen die Strukturen hässlich aus. Guck dir mal an, wie XML::Simple versucht, die Serialisierung hinzubekommen, und wieviele Optionen man einschalten muss, um das gewünschte Format zu bekommen.

Leider hat noch niemand XML::Simple::Schema geschrieben...

Quote

In der Welt der Lispdialekte, in der ich mich oft bewege, kann man dann natürlich noch ganz portabel S-Expressions zur Serialisierung nehmen. Kann mehr als XML, ist aber einfacher und speichereffizienter. Keine Ahnung, ob es dafür ein Perlmodul gibt, aber es ist auch (leider) nicht so verbreitet unter Leuten, die kein Scheme, Common Lisp oder ähnliches programmieren.

-> JSON. Das ist portabel (für viele Sprachen anwendbar), nicht ganz so lesbar wie YAML, aber dafür viel einfacher gestrickt.

[quote=ptk,08.02.2006, 20:25][...]
Das wäre *keine* Serialisierung, weil man nur einfache Hashes abbilden kann.[/quote]
Zum einen habe ich das nicht direkt behauptet, zum anderen halte ich es für eine Definitionsfrage. Wenn man nur solche Datenspeichermethoden als Serialisierung bezeichnet, die die gesamte Palette an Datentypen einer Sprache bijektiv in einen Permanentspeicher abbilden können, dann gibt es für Perl (und auch für die meisten anderen Sprachen) überhaupt keine echte Serialisierungsmöglichkeit -- oder kennt hier jemand ein Modul, das zum Beispiel auch Subroutinen, XS Funktionen, Typeglobs und Dateihandles speichern kann?

Ich tendiere eher zu der pragmatischen Definition, dass alles, was eine für meinen momentanen Anwendungszweck sinnvolle Teilmenge der Datentypen meiner gerade verwendeten Programmiersprache in portabler Form bijektiv in einen Festspeicher abbildet, ein Serialisierungssystem ist.

[quote=ptk,08.02.2006, 20:25][...] Oder man will es menschenlesbar haben, dann nimmt man Data::Dumper. Leider muss man hier beim Rückumwandeln eval() verwenden --- nicht sehr sicher.[/quote]
Alles was beim Einlesen von Daten arbiträren Code ausführt, ist für ernsthafte Anwendungen nur sehr bedingt geeignet. Ich finde Data::Dumper ist ein hervorragendes Debuggingwerkzeug, als Datenspeicherformat würde ich die Ausgabe jedoch ungern verwenden.

Ich hätte mir aber schon öfters ein eingebautes Interface von Perl zu seinem Parser gewünscht, so dass man Data::Dumper-Ausgaben als Speicherformat verwenden könnte, allerhand lustige Transformationen an Programmcode nicht fehleranfällig auf textueller Ebene machen müsste und dergleichen mehr.

[quote=ptk,08.02.2006, 20:25][...]Das Problem ist: man kann Perl-Datenstrukturen nicht 1:1 nach XML und umgekehrt umwandeln. OK, man kann schon, aber dann sehen die Strukturen hässlich aus.[/quote]
Ich habe ja nie behauptet, dass XML toll oder sinnvoll wäre -- es funktioniert nur im Gegensatz zu vielem Anderem fast überall.

[quote=ptk,08.02.2006, 20:25][...]-> JSON. Das ist portabel (für viele Sprachen anwendbar), nicht ganz so lesbar wie YAML, aber dafür viel einfacher gestrickt.[/quote]
Das ist ein hübsches Format, hat aber auch immer noch einen Nischenstatus.

(edit: Forumsartefakt entfernt)\n\n

<!--EDIT|murphy|1139453325-->

[quote=murphy,09.02.2006, 03:45][quote=ptk,08.02.2006, 20:25][...]
Das wäre *keine* Serialisierung, weil man nur einfache Hashes abbilden kann.[/quote]
Zum einen habe ich das nicht direkt behauptet,
[/quote]Ich habe das aus "Serialisierungsformat" abgeleitet, hast du davor geschrieben.

Quote

zum anderen halte ich es für eine Definitionsfrage. Wenn man nur solche Datenspeichermethoden als Serialisierung bezeichnet, die die gesamte Palette an Datentypen einer Sprache bijektiv in einen Permanentspeicher abbilden können, dann gibt es für Perl (und auch für die meisten anderen Sprachen) überhaupt keine echte Serialisierungsmöglichkeit -- oder kennt hier jemand ein Modul, das zum Beispiel auch Subroutinen, XS Funktionen, Typeglobs und Dateihandles speichern kann?

Storable und Data::Dumper können, wenn das entsprechende Flag gesetzt ist, auch Subroutinen serialisieren, Storable auch deserialisieren. Bei den anderen Typen wird es schwierig.

Quote

Ich tendiere eher zu der pragmatischen Definition, dass alles, was eine für meinen momentanen Anwendungszweck sinnvolle Teilmenge der Datentypen meiner gerade verwendeten Programmiersprache in portabler Form bijektiv in einen Festspeicher abbildet, ein Serialisierungssystem ist.

Und ich habe zu oft den Fall, dass ich auch ein bisschen tiefere Datenstrukturen verwende. Deshalb habe ich mir INI nie angeschaut.

Quote

[quote=ptk,08.02.2006, 20:25][...]Das Problem ist: man kann Perl-Datenstrukturen nicht 1:1 nach XML und umgekehrt umwandeln. OK, man kann schon, aber dann sehen die Strukturen hässlich aus.

Ich habe ja nie behauptet, dass XML toll oder sinnvoll wäre -- es funktioniert nur im Gegensatz zu vielem Anderem fast überall.[/quote]Ernsthaft? Ich kann mich nie erinnern, dass bei mir eine B2B-Kommunikation über XML fehlerlos über die Bühne gegangen ist. Meistens muss man vorher noch Preprocessing machen, um das kaputte XML geradezubiegen oder XML::LibXML zum "vergebenden" Parsen zwingen. XML sieht einfach aus und Leute glauben, dass es einfach ist, XML zu produzieren. Leider ist das nicht so.

[quote=ptk,09.02.2006, 09:05]Und ich habe zu oft den Fall, dass ich auch ein bisschen tiefere Datenstrukturen verwende. Deshalb habe ich mir INI nie angeschaut.[/quote]
Mit Config::Inifiles geht sehr viel zu machen.

ini ist nicht nur
[section]
Parameter=Value

sondern auch:
# Section-Kommentare über das Modul les- und veränderbar
[section]
# Parameter-Kommentare über das Modul les- und veränderbar
Parameter1=Value1
# Multivalue
Parameter2=<<EOT
Value1
Value2
EOT

ptk meint mit "tieferen Datenstrukturen" wohl eher sowas wie HoH oder AoH etc...