Frage zum Wiki-Artikel „Referenzen“

[Perlentaucher]

Hallo!

Sind die Anweisungen:

my $Subroutinenzeiger = &Zufallswert;

my $Referenzergebnis = &{$Subroutinenzeiger}();

die dem Programm unter der Überschrift "Referenzen und Subroutinen" richtig geschrieben? Im darauf folgenden erläuternden Text zum Programm werden die Anweisungen so geschrieben:

my $Subroutinenzeiger = &Zufallswert

my $Referenzergebnis = &{$Subroutinenzeiger}()

Für mich sieht es so aus, als ob das &-Zeichen in der HTML-Umschreibung vorliegt. Ich meine, dass die Buchstaben a, m, p entfernt werden müssten. Ich bin mir meiner Einschätzung nicht sicher und möchte die Seite nicht bearbeiten und lieber das Forum entscheiden lassen. Vielen Dank!

[Perlentaucher]

Ich bitte um Entschuldigung für die Zuweisung falscher Tags. Ich habe die Sache missverstanden. Leider konnte ich meine Anfrage dahingehend nicht mehr ändern, da ich als unangemeldeter Nutzer diese Anfrage stellte.

[Matthias Apsel]

Hallo Perlentaucher,

Ich bitte um Entschuldigung für die Zuweisung falscher Tags.

Kein Problem.

Bis demnächst
Matthias

[pl]

Der Begriff Zeiger ist auf jeden Fall nicht richtig und in dem Zusammenhang auch der Vergleich mit c nicht. Die Schreibweise mit Ampersand ist veraltet. Zum Dereferenzieren ist seit Perl-Version 5 (um das Jahr 2001) der Pfeil-Operator gebräuchlich.

Der Artikel scheint aus der Zeit eines Perl 4 oder gar Perl 3 zu kommen. Einen richtig guten Einstieg hingegen findest Du mit Eric Foster Johnson "Perl Module" Verlag mitp, isbn 3-8266-0570-5 das ist von 1999, fachlich kompetenter nirgendwo so formuliert. Also keineswegs veraltet.

PS: Ich kenne wirklich keinen Perl-Entwickler der so programmiert wie es SELFHTML vermittelt.

[JürgenB]

Hallo Rolf,

Der Artikel scheint aus der Zeit eines Perl 4 oder gar Perl 3 zu kommen.

hättest du denn Lust, den Artikel zu überarbeiten? Perl ist doch dein Ding.

Gruß
Jürgen

[Christian Kruse]

Hallo JürgenB,

Der Artikel scheint aus der Zeit eines Perl 4 oder gar Perl 3 zu kommen.

hättest du denn Lust, den Artikel zu überarbeiten? Perl ist doch dein Ding.

Der Perl-Teil von SELFHTML sollte lieber gestrichen werden… das habe ich auch damals™ schon gesagt. Der war noch nie gut…

LG,
CK

[Camping_RIDER]

Aloha ;)

Der Artikel scheint aus der Zeit eines Perl 4 oder gar Perl 3 zu kommen.

hättest du denn Lust, den Artikel zu überarbeiten? Perl ist doch dein Ding.

Der Perl-Teil von SELFHTML sollte lieber gestrichen werden… das habe ich auch damals™ schon gesagt. Der war noch nie gut…

Meine Zustimmung hast du dazu. Wir müssen uns auf Kernkompetenzen konzentrieren und uns fehlt im Perl-Bereich schlicht die Manpower um die veralteten Artikel irgendwie auf aktuellen Stand zu bekommen - und vor allem hat Perl heutzutage einfach nicht mehr den Stellenwert beziehungsweise die Relevanz, damit wir sagen müssten wir könnten im Wiki auf Perl nicht verzichten.

Grüße,

RIDER

[pl]

Perl ist erst tot, wenn ich es bin 😉

Mein Framework in PHP -- nee, guck mal wie einfach das in Perl ist, hab grad ein schönes Beispiel: Die Seite DST soll interaktiv werden, also Benutzereingaben ermöglichen.

Als Erstes werden Platzhalter fürs Ergebnis eingbaut: %mrz%, %okt% und %next% hierauf kommen 2 Datumsangaben und ein Jahr.

Als Nächstes bekommt die Seite ein Interface konfiguriert interface = dst

und in dieser Datei steht eine Funktionsreferenz:

# Datei interface/dst.pm

my $control = sub{
    my $self = shift;
    if( my $year = $self->param('next') ){
        my $mrz = Scaliger->new( date => "31.3.$year" ) or 
          return $self->errmsg( "$@" , $self->{URL});

        my $okt = Scaliger->new( date => "31.10.$year" ) or 
          return $self->errmsg( "$@" , $self->{URL});

        $self->{STASH}{mrz} = sprintf("%02d.03.%d", 31 - $mrz->wd, $year );
        $self->{STASH}{okt} = sprintf("%02d.10.%d", 31 - $okt->wd, $year );
        
        $self->eav('title', "Beginn und Ende der Sommerzeit im Jahr $year");
        $self->eav(
          'descr', 
           "Zu bestimmen ist der letzte Sonntag im März bzw. Oktober $year, Ergebnis untenstehend"
        );
        $self->{STASH}{next} = $year + 1;
    }
};

Die Funktion wird aufgerufen, wenn GET- oder POST−Parameter im Request sind und setzt einfach nur die berechneten Platzhalter in $self->{STASH}, je nachdem, welches Jahr eingegeben wurde. D.h., zum Erweitern einer statischen HTML-Seite damit Benutzereingaben möglich werden, ist lediglich eine Funktion in einer minimalen Moduldatei zu definieren.

Das HTML ums Formular erweiteren ist ein Witz, zumal die Fehlerbehandlung automatisch eingebaut ist. Des Weiteren: Das Interface dst.pm kann an beliebig weitere HTML-Seiten per Konfiguration zugewiesen werden zum Einbau dynamischer Inhalte DST betreffend. Das vermeidet Coderedundanzen und das ist eben Perl.

MfG

[Camping_RIDER]

Aloha ;)

Perl ist erst tot, wenn ich es bin 😉

Was das Forum angeht habe ich da keinerlei Zweifel 😂

Grüße,

RIDER

[pl]

Hi,

Perl lebt, Perl ist tot, ja es stimmt Beides. Betrachte CGI.pm, die meisten Perl-Entwickler binden das nur ein, um Parameter parsen zu können. Dafür kennt dieses Modul lächerliche 2 Content-Types:

application/x-www-form-urlencoded und multipart/form-data

so als wäre die Entwicklung seit 20 Jahren stehengeblieben. CGI.pm ist tot, toter geht nicht. Aber davon abgesehen ist multipart/form-data auch Schrott, das war es schon immer. Täglich landen rund 50 neue Module auf CPAN, auch neue Frameworks sind dabei.

Aber seit 20 Jahren gibt es zu CGI.pm keine Alternative, zumal es jede Menge neue Content-Types gibt, xml, json usw. die in den letzten 20 Jahren hinzugekommen sind. Angesichts dieser ungeheuerlichen Schieflage frage ich mich, was Entwickler eigentlich von Perl 6 erwarten -- Ein Wunder vielleicht!?

Dabei ist es geradezu ein Witz, die Parameter eines Enctype="application/x-www-form-urlencoded" zu parsen und als Erweiterung auf andere Enctypes wären lediglich die entsprechenden Module einzubinden -- Alles liegt griffbereit auf CPAN nur: Es kommt keiner auf die Idee, CGI.pm entsprechend zu erweitern und dafür den unnützen Ballast wegzuschmeißen den CGI.pm seit Jahrzehnten mit sich rumschleppt und den ohnehin kaum jemand nutzt.

Die File-API moderner Browser macht multipart/form-data überflüssig. Ne, CGI.pm brauche ich schon lange nicht mehr. Zumal nicht einmal die Request-Method darüber entscheidet, ob Daten serverseitig aus STDIN gelesen werden müssen sondern einzig der Header Content-Length. Komisch, dass das noch niemanden weiter aufgefallen ist, die ganze Logik in CGI.pm geht an der Schnittstellendefinition CGI/1.1 glatt vorbei und das seit Jahrzehnten.

Und welcher Webserver ist schon so strikt konfiguriert, dass er nur RFC-gerechte Request-Methoden zulässt?

Na, ich werd' mal den Artikel angehen...

[anonym]

seit 20 Jahren gibt es zu CGI.pm keine Alternative

Die heißt Plack/PSGI und der Grund, warum CGI.pm stilvoll zu Grabe getragen wurde. Das ist, wie sich zum x-ten Mal im Bereich Perl zeigt, mal wieder komplett an dir vorbeigegangen.

http://plackperl.org/ https://p3rl.org/Plack

[pl]

PSGI/Plack sind mir bekannt. Ist jedoch keine Lösung für die beschrieben Mängel an CGI.pm. Außerdem ergeben sich keine Vorteile gegenüber Legacy, wenn die Serverumgebung %ENV, die ein Webserver lt. CGI/1.1 Standard ohnehin anlegen muss, innerhalb von Perl gekapselt wird.

Denn CGI/1.1 umfasst nämlich nicht nur die Serverumgebung sondern auch STDIN/STDOUT und das lässt sich gar nicht kapseln -- auch mit PSGI nicht. PSGI ist ein typisches Beispiel für alten Wein in neuen Schläuchen und daher weder eine Alternative zu CGI.pm noch eine Weiterentwicklung von CGI/1.1 im innovativen Sinne.

Genau hier an dieser Stelle bietet sich ein Verweis auf die uralte Doku SELFHTML/Perl an, weil der Parser, der damals in dieser Doku vorgestellt wurde, gleichermaßen die CGI/1.1 Standard erklärt hat, das war so um 1997.

Die seit 20 Jahren fällige Weiterentwicklung von CGI.pm könnte so aussehen:

sub _parse_rawdata{
    my $self = shift;
    if(    $self->{CONTENT_TYPE} eq 'multipart/c-eav' ){
        require cEAV;
        $self->{eav} = cEAV->decode_eav( $self->rawdata );
        $self->{param} = $self->{eav}->{param};
    }
    elsif( $self->{CONTENT_TYPE} eq 'multipart/eav' ){
        # coming soon
    }
    elsif( $self->{CONTENT_TYPE} eq 'multipart/form-data' ){
        require ParseMultipart;
        $self->{STDIN}->seek(0,0);
        $self->{param} = ParseMultipart->parse_multipart( $self->{STDIN} );
    }
    elsif( $self->{CONTENT_TYPE} eq 'application/json' ){
        require JSON;
        my $json = JSON->new;
        $self->{json} = $json->decode($self->rawdata);
        $self->{param} = $self->{json}{param};
    }
    elsif( $self->{CONTENT_TYPE} eq 'bserialize/av' ){
        require bSerialize;
        my $bs = bSerialize->new;
        my $binary = $self->rawdata;
        $self->{param} = $bs->bin2av( \$binary );
    }
    elsif( $self->{CONTENT_TYPE} eq 'bserialize/eav' ){
        require bSerialize;
        my $bs = bSerialize->new;
        my $binary = $self->rawdata;
        $self->{eav}   = $bs->bin2eav( \$binary ); 
        $self->{param} = $self->{eav}{param};
    }
    elsif( $self->{CONTENT_TYPE} eq 'application/body+query' ){
        # QUERY_STRING mit Parametern + Message Body mit Binary
        $self->{param} = $self->qparse($self->{QUERY_STRING});
    }
    else{
        # Default Enctype
        # Parameter: Name => [Value], application/x-www-form-urlencoded
        $self->{param} = $self->qparse($self->rawdata);
    }
}

und genau hier liegt der Hase im Pfeffer: Eine solche Kontrollstruktur ist beliebig erweiterbar für beliebige Content-Types. Und auch ein schönes Beispiel dafür, wie CODE zweckmäßig, nämlich nur bei Bedarf nachgeladen werden kann. Siehe auch hier über den Sinn des Request-Headers Content-Type.

MfG

[anonym]

[Plack] Ist jedoch keine Lösung für die beschrieben Mängel an CGI.pm.

Begründung fehlt.

Außerdem ergeben sich keine Vorteile gegenüber Legacy, wenn die Serverumgebung %ENV, die ein Webserver lt. CGI/1.1 Standard ohnehin anlegen muss, innerhalb von Perl gekapselt wird. Denn CGI/1.1 umfasst nämlich […] auch STDIN/STDOUT und das lässt sich gar nicht kapseln -- auch mit PSGI nicht.

Du hast den Beweggrund und die Funktionsweise von Plack überhaupt nicht verstanden. Es gibt mehr als ein Gateway-Interface. Eine Plackanwendung braucht in seinem Serverprozess nicht zwingend Umgebungsvariablen setzen, ebensowenig werden die Standardstreams gekapselt. Plack bietet eine Abstraktion über Gateway-Interfaces. Sofern der Entwickler Deployment auf CGI wünscht, werden erst dann besagte Erfordernisse reifiziert. Aber wer will/braucht schon Deployment auf CGI? Alle anderen Interfaces sind besser.

PSGI ist ein typisches Beispiel für alten Wein in neuen Schläuchen

Begründung fehlt.

Die seit 20 Jahren fällige Weiterentwicklung von CGI.pm könnte so aussehen:

Ich lachte herzlich. Früher Aprilscherz, nehme ich an‽ Willst du wirklich, dass jedes Mal, wenn du dir einen neuen Mediatype aus dem Allerwertesten popelst (netter Verstoß gegen RFC 6838 §3.1. übrigens, du Internetverderber), der Maintainer für dich persönlich Code an den Switch anfügt?

Würdest du OOP einsetzen, könntest du das mittels Polymorphismus statt Switch (http://wiki.c2.com/?ReplaceConditionalWithPolymorphism, https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism) in deiner eigens abgeleiteten Klasse regeln, ohne anderen Leuten auf die Nüsse zu gehen. Und das muss auch nicht im der HTTP-Lib oder im Framework sein, es ist vollkommen kromulent, das im Clientcode zu regeln, siehe wirkliches Beispiel in http://p3rl.org/Catalyst#DATA-HANDLERS.

Und wofür gibt's eigentlich Middlewares? Öh, öhm ach ja…

[pl]

Begründung fehlt.

Nana, ich hab das ausführlich begründet. Ergänzung: Es gab noch nie einen wirklichen Grund dafür, CGI.pm einzusetzen weil es

1. schon immer andere und zweckmäßigere Lösungen gab HTML zu erzeugen, nämlich über Templates,
2. schon immer andere und zweckmäßigere Lösungen gab, Response-Header zu erzeugen und zu puffern, nämlich über einen sinnvollen Einsatz einer objektorientierten Programmierung,
3. schon immer andere und zweckmäßigere Lösungen gab, die ganze Ausgabe in Richtung STDOUT zu puffern (auch OOP),
4. schon immer andere und zweckmäßigere Lösungen gab, Parameter zu parsen, ohne dass hierzu fünftausend Zeilen CODE (CGI.pm) kompiliert werden müssen.

Mit PSGI, Catalyst usw. werden ganz andere Ziele verfolgt. Was den CGI/1.1 Standard betrifft: Diese Schnittstelle ermöglicht, dass sämtliche Parameter eines HTTP-Request durch den Webserver hindurch einem nachgelagerten Prozess zur Verfügung stehen, das Gateway umfasst:

1. STDIN, STDOUT,
2. die Serverumgebung.

Man kann auch sagen, der Webserver wird dadurch transparent (durchsichtig). In Fakt schickt der CGI-Prozess (Perl, PHP) die HTTP-Response nach STDOUT, das Einzige, was hierzu bekannt sein muss, ist die Frage, ob der Webserver die Response-Header parst oder ob der CGI-Prozess selber für die Header zuständig sein soll (Non Parsed Header Scipts). Ansonsten ist einem CGI-Prozess der Webserver völlig Luft, der guckt durch den hindurch als gäbe es den gar nicht.

PSGI beschreibt lediglich eine andere Art und Weise des Zugriff auf die Serverumgebung.

MfG

[pl]

Auch das ist CGI.pm:

If POSTed data is not of type application/x-www-form-urlencoded or multipart/form-data, then the POSTed data will not be processed, but instead be returned as-is in a parameter named POSTDATA. To retrieve it, use code like this:... Likewise if PUTed data.

WTF! Und was haben PSGI oder Plack dieser Unlogik entgegenzusetzen? Nichts! Da wurde nämlich selbst mit PHP besser verstanden, dass es unabhängig vom gesendeten Content-Type sowohl aus STDIN als auch aus der Serverumgebung (QUERY_STRING) Daten zu lesen gibt.

Genaugnommen wären aus STDIN nur dann Daten (HTTP-Request-Body) zu lesen, wenn der Client die Anzahl der zu lesenden Bytes > 0 in einem Request-Header namens Content-Length sendet UND der Webserver diese Angabe als CONTENT_LENGTH in die Serverumgebung setzt -- Und das ist sowohl vom Content-Type als auch von der Request-Methode unabhängig.

Praktisch ist STDIN nur dann zu lesen, wenn die Request-Methode PUT oder POST ist. Auch dieser Fakt ist in CGI.pm mangelhaft interpretiert, ich zitiere:

If set $CGI::POST_MAX to a non-negative integer, this variable puts a ceiling on the size of POSTings, in bytes. If CGI.pm detects a POST that is greater than the ceiling, it will immediately exit with an error message. This value will affect both ordinary POSTs and multipart POSTs, meaning that it limits the maximum size of file uploads as well. You should set this to a reasonably high value, such as 10 megabytes.

Da kann also jeder diese Regel umgehen, indem er eine andere Request-Methode wählt. Was hat PSGI dem entegenzusetzen? Nichts!

Allein aus den seit 20 Jahren in CGI.pm verbauten Unzulänglichkeiten siehst Du doch selbst, dass PSGI/Plack keine Alternative ist. Die einzige Alternative ist, den Mängeln in CGI.pm mit einer zweckmäßigen Art und Weise der Programmierung zu begegnen wozu auch ein sinnvoller Einsatz der OOP gehört -- und genau das war schon im Jahr 2001 möglich, also ab Version 5.

Die Entscheidung für Middleware wie Plack usw. musst Du freilich selber treffen. Ich empfehle dir jedoch, Du solltest Dich einmal mehr mit den Gundlagen befassen um den Stellenwert solcher Frameworks überhaupt einschätzen zu können.

Schönen Tag auch 😉

[pl]

Ich lachte herzlich. Früher Aprilscherz, nehme ich an‽ Willst du wirklich, dass jedes Mal, wenn du dir einen neuen Mediatype aus dem Allerwertesten popelst

Klingt ziemlich ordinär aber auch darauf werde ich Dir antworten. Proprietäre Content-Types sind absolut legitim wenn es darum geht, Daten zu übertragen; denn das was es an neuen Content-Types in die einschlägigen RFCs schafft, ist bei weitem nicht ausreichend, alle Anforderungen abzudecken.

Neue, RFC-gerechte Content-Types wie zb. application/json oder /xml beschreiben nämlich allenfalls die Art und Weise der Serialisierung, was sie nicht beschreiben ist der Abstrakte Datentyp selbst -- Und das ist ein ganz wesentlicher Unterschied zu application/x-www-form-urlencoded und multipart/form-data.

Im meiner Kontrollstruktur:

    elsif( $self->{CONTENT_TYPE} eq 'application/json' ){
        require JSON;
        my $json = JSON->new;
        $self->{json} = $json->decode($self->rawdata);
        $self->{param} = $self->{json}{param};
    }

werde ich diesem Umstand gerecht, indem ein Teil der Datenstruktur als Referenz, soweit vorhanden, auf den Schlüssel 'param' ausgegliedert wird. Somit wird nämlich auch der Parser für den Content-Type transparent, d.h., eine clientseitige Umstellung von application/x-www-form-urlencoded nach application/json erfordert nicht eine Zeile serverseitigen CODE zu ändern.

Das ist die Idee, die dahinter steckt und dass Du das nicht erkannt hast sondern ganz arrogant versuchst schlechtzureden zeugt nur davon, dass Dir sowohl Grundwissen als auch abstrakte Denkweisen fehlen.

anonym ist der passende Nick für solche Zeitgenossen wie Du es bist und auch für Diejenigen die hier fleißig mit -- bewerten.

Ich finds schade, dass das Niveau dieses Forums auf einen solchen Tiefstand gekommen ist. MfG

[JürgenB]

Hallo Christian,

Der Perl-Teil von SELFHTML sollte lieber gestrichen werden… das habe ich auch damals™ schon gesagt. Der war noch nie gut…

ich meine auch, das der Perl-Teil nicht zwingend nötig ist. Aber warten wir mal ab, ob Rolf da was beitragen möchte. Sonst kann man da ja Links setzen.

Gruß
Jürgen

[Matthias Apsel]

Hallo Christian Kruse,

Der Perl-Teil von SELFHTML sollte lieber gestrichen werden… das habe ich auch damals™ schon gesagt. Der war noch nie gut…

Ich vertraue deiner Einschätzung.

Bis demnächst
Matthias

[Perlentaucher]

Hallo!

Ooh, da habe ich wohl in ein Wespennest gestochen. Mir war nicht bewusst, dass so konträre Ansichten zu der Perl-Anleitung bestehen. Meine Intension war, meine verschütteten und nur rudimentären Kenntnisse aus der Schulzeit aufzufrischen und ein einfaches Verständnis zu entwickeln, wie Programmieren geht. Und da möchte ich für die Perl-Anleitung eine Lanze brechen. Ich habe die bisher gelesenen Artikel prinzipiell verstanden, ohne die Programmierung aus dem FF zu beherrschen. Dafür fehlt mir die Erfahrung, und dies ist auch nicht meine Absicht.

Vielleicht sollten die einzelnen Artikel zu Perl dahingehend gekennzeichnet werden, wann sie für welche Version von Perl erstellt oder durch Überarbeitung an eine aktuellere Versionen angepasst wurden.

Sicherlich steht der Name der Internetseite für HTML und damit das Gestalten von Internetseiten. Dazu die verfeinerte Form der Gestaltung via CSS könnte ausreichend sein für den Internetauftritt. Dennoch sehe ich es als nicht verkehrt an, Möglichkeiten aufzuführen, wie interaktive Seiten erstellt werden könnten. Wenn in diesen Zusammenhang die Darbietung von Perl (oder PHP) zu fehlerhaft ist, weil so in der Praxis nicht programmiert wird, bliebe die Erweiterung des Internetauftritts dahingehend, dass ein gängiges CMS und dessen Möglichkeiten vorgestellt werden.

Ich fand bisher den Internetauftritt sehr hilfreich und werde noch ein wenig bei Perl verweilen und damit hoffentlich mein Grundverständnis erweitern.

[pl]

Wie bereits festgestellt: Jede Perl-Installation kommt mit einer umfangreichen Dokumentation daher. Ein perldoc perlref auf der Kommandozeile liefert Dir ebenfalls einen sehr gut verständlichen Artikel zu Referenzen -- Ohne die es in Perl gar nicht möglich wäre, über assoziative Arrays hinausgehende tiefere Datenstrukturen zu erzeugen!

Kontrovers zu diskutieren wäre höchstens, wie es in der Praxis umgesetzt wird. Es gibt nämlich auch gute Gründe, auf Referenzen zu verzichten und Funktionsargumente als native Hash zu übergeben, insbesondere dann, wenn Defaults (fehlende Werte) zu setzen sind -- ist aber nicht Perl-spezifisch.

MfG

[pl]

Moin Jürgen,

überarbeiten -- nein, weg damit! Aber ich werde einen neuen Artikel schreiben und zwar so, dass den jeder versteht. Referenzen in Perl sind überhaupt nichts Kompliziertes, wenn man das einmal verstanden hat, kommen einem die Ideen, was man alles damit machen kann von ganz alleine.

Hier ein CPAN-Modul von mir, was mit schlappen 100 Zeilen das Thema "Referenzen in Perl" schon fast ausschöpft.

MfG

PS: Jede Perl-Installation bringt eine sehr umfangreiche Doku mit, als pod, text und html! Und jedes Nachinstallieren von CPAN-Modulen hängt die POD sowie an der richtigen Stelle ein.

[pl]

Erster Entwurf, lag noch irgenwo rum 😉