Frage zum Wiki-Artikel „Funktionen für Zeichenketten“
Perlentaucher
- frage zum wiki
Hallo!
Ich kopierte das Script vom Abschnitt "chr - Zeichen eines Zeichenwerts ermitteln" und fügte es im gedit (UTF8) ein. Ich rufe die Datei im Terminal auf und es wird eine Tabelle im HTML-Code ausgegeben. Bei der 13. Zelle "verschluckt" sich der Perl-Code. Es wird ein falscher HTML-Tag angegeben und statt einer 13 eine 3 (so </td>3= , statt <td>13 = </td>). Woran kann das liegen?
Hier der Fehler im ausgegebenen HTML-Code (gekürzt):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head><title>Test-Ausgabe</title></head>
<body>
<table border="1" bgcolor="#FFFFE0">
<tr>
<td>0 = </td>
<td>1 = </td>
<td>2 = </td>
<td>3 = </td>
<td>4 = </td>
<td>5 = </td>
<td>6 = </td>
<td>7 = </td>
</tr>
<tr>
<td>8 =</td>
<td>9 = </td>
<td>10 =
</td>
<td>11 =
</td>
<td>12 =
</td>
</td>3 =
<td>14 = </td>
<td>15 = </td>
</tr>
Vielen Dank!
Hallo,
Woran kann das liegen?
Daran, dass du versuchst Steuerzeichen auszugeben. du könntest recherchieren, was dieses 13. Steuerzeichen tut. Ich tippe mal auf "Zeile löschen"
Gruß
Kalk
Dankeschön! Auf so einen Gedanken wäre ich nie gekommen! Ich recherchierte und fand, dass das 13. Steuerzeichen ein CR ausgibt und dies gleichbedeutend für Wagenrückruf (\r) ist. Es gibt eine Menge Fallstricke für einen Laien, über die gestolpert werden kann.
Na, Du hattest doch letztens die Referenzen am Wickel. Dann machen wir doch gleich einmal ein Beispiel für Modernes Perl und nehmen statt der umständlichen print()-Ausgabe doch gleich eine richtige Templating Engine:
#!/usr/bin/perl
use strict;
use warnings;
use HTML::Template;
# Lese Handler DATA
# übergebe Scalar Referenz
my $data = do{ local $/ = undef; <DATA> };
# TE Instanz erstellen
my $template = HTML::Template->new( scalarref => \$data );
# Daten erzeugen
my @slice = ();
foreach my $num( 0..127 ){
push @slice, {
ord => $num,
chr => chr($num)
};
}
# Daten an TE Instanz übergeben
# als Referenz auf das Array
$template->param(chars => \@slice);
# Template rendern und ausgeben
print $template->output();
# Template unterhalb DATA Token
__DATA__
<table>
<thead>
<tr>
<th> ASCII Numerisch </th>
<th> Zeichen </th>
</tr>
</thead>
<tbody>
<TMPL_LOOP name="chars">
<tr>
<td> <TMPL_VAR name="ord"> </td>
<td> <TMPL_VAR name="chr"> </td>
</tr>
</TMPL_LOOP>
</tbody>
</table>
Und das ist doch mal ein schönes Beispiel, wie man mit Perl einen ordentlichen Code schreiben kann.
Machs besser 😉
PS: Escapen nicht vergessen, das kann die TE, siehe untenstehend:
<td> <TMPL_VAR name="chr" ESCAPE=HTML> </td>
Hallo!
Und das ist doch mal ein schönes Beispiel, wie man mit Perl einen ordentlichen Code schreiben kann.
Ich wäre schon froh, eine Einkaufsliste schreiben zu können. Doch so ein Gedicht zu verstehen und selbst zu verfassen, sehe ich als hohe Kunst für Fortgeschrittene an.
Ach das kann man alles lernen, Schritt für Schritt. Wichtig ist, den Sinn und Zweck zu erkennen, warum ein Template: Um Code und Layout sauber zu trennen.
Und soo kompliziert ist mein Beispiel nun auch wieder nicht 😉
PS: Das Markdown vom Forum hat einen Backslash gefressen. Hier isser nochmal nachgereicht:
$template->param( chars => \\@slice );
Indes: Übergeben wird ein Schlüssel und ein Wert. Und der Wert in einem Hash ist grundsätzlich immer ein Scalar. Also kann es nur eine Refernez sein, steht auch weiter oben im Kommentar.
MfG
Tach!
Ach das kann man alles lernen, Schritt für Schritt. Wichtig ist, den Sinn und Zweck zu erkennen, warum ein Template: Um Code und Layout sauber zu trennen.
Es gibt auch andere Vorgehensweisen, Programme zu strukturieren. Im obigen Fall wird die Trennlinie zwischen verschiedenen Sorten von Code gezogen, hier Perl und HTML. Nun ist es aber so, dass auch in der Ausgabe Logik benötigt wird, um bestimmte Bereiche in Abhängigkeit auszugeben oder nicht, oder Bereiche wiederholt darzustellen, oder auch nur, um zu kennzeichnen, dass da Variableninhalte ausgegeben werden sollen. Man löst das Problem hierbei, indem man eine dritte Sorte Code hinzunimmt: template-engine-spezifische Syntax. Und natürlich braucht man auch noch die Template-Engine, die das Template parsen muss, die zusätzlichen Syntaxelemente erkennen und entsprechenden Code ausführen muss, um die Ausgabe nach Wunsch zu erzeugen.
Das Ziel, (Programm-)Code von Layout(-Code) zu trennen, ist auf diese Weise nicht erreichbar, wenn lediglich der eine Code (Template-Syntax) einen anderen Code (den der eigentlich verwendeten Programmiersprache) ersetzt. Im Prinzip ist es gar nicht erreichbar, solange irgendeine Art der Steuerung benötigt wird, um die Ausgabe zu erzeugen.
Eine andere sehr übliche Herangehensweise ist, die Trennlinie zwischen der Geschäftslogik (das was das Programm hauptsächlich tun soll) und der Ausgabe zu ziehen. Für die Steuerung der Ausgabe verwendet man dann einfach eingebetteten Code derjenigen Programmiersprache, die man sowieso schon verwendet. Meist beschränkt sich die Ausgabelogik auf if-then-else, Schleifen, Variablenausgabe sowie Maskierungsfunktionen.
Template-Engines mit eigener Syntax haben aber auch ihren Nutzen. Zum Beispiel dann, wenn die Templates von Personen ohne Programmierhintergrund erstellt werden sollen und sie lediglich die vereinfachte Syntax und die eingeschränkten Möglichkeiten der Template-Engine verwenden müssen. Im Prinzip bleibt es sich aber gleich, ob sie die drei Elemente in der einen Sprache oder der anderen erlernen müssen. Syntaktisch fehlerfrei müssen sie in jedem Fall arbeiten.
dedlfix.
Nun ist es aber so, dass auch in der Ausgabe Logik benötigt wird, um bestimmte Bereiche in Abhängigkeit auszugeben oder nicht, oder Bereiche wiederholt darzustellen, oder auch nur, um zu kennzeichnen, dass da Variableninhalte ausgegeben werden sollen. Man löst das Problem hierbei, indem man eine dritte Sorte Code hinzunimmt: template-engine-spezifische Syntax.
Kann man. Es gibt aber auch andere Lösungen, das View umzuschalten. Wir haben das hier mal diskutiert vor vielen Jahren. Und selbstverständlich kann die hier gezeigte TE "bestimmte Bereiche wiederholt darstellen" man nennt das LOOP, siehe mein Beispiel. MfG
Ergänzung:
Der Artikel ist überarbeitungsbedürftig. Weil: Seit Version 5 unterstützt Perl Zeichenketten mit einer bestimmten Kodierung. D.h., vor der Anwendung von Funktionen die mit Zeichenketten zu tun haben, muss dem Interpreter mitgeteilt werden, dass er nicht byteorientiert sondern zeichenorientiert arbeiten soll und das mit einer bestimmten Kodierung die hierzu ebenfalls dem Interpreter mitzuteilen ist.
Dem geschuldet ist seit Version 5.8 das Module Encode
im Core jeder Distribution. Dieses Modul vermittelt zwischen Character- und Bytesemantic.
MfG
Hallo pl,
Der Artikel ist überarbeitungsbedürftig. Weil: Seit Version 5 unterstützt Perl Zeichenketten mit einer bestimmten Kodierung.
<I>
Auf der ganzen Perlschiene wurde seit 2012 nichts gemacht. Und das war m.W. auch nur eine unveränderte Übernahme aus der Doku.
Bis demnächst
Matthias
Auf der ganzen Perlschiene wurde seit 2012 nichts gemacht.
Perl unterstützt Unicode seit dem Jahr 2001. Seit Version 5 im Jahr 2001 wurde die Unterstützung von Zeichenkodierungen kontinuierlich weiterentwickelt. Und mit v5.8 kam das Modul Encode in den Core, das war im Jahr 2010.
Soweit zu Deinem Statement. MfG
Hallo pl,
Soweit zu Deinem Statement.
Du hast sinnentstellend zitiert. Damit ist deine… „Kritik” völlig hinfällig.
Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.
LG,
CK
Hallo Christian Kruse,
Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.
Da sind wir schon mindestens zwei. Ein weiteres Argument wäre die Fokussierung auf die Kernthemen. Perl ist kein Kernthema.
Bis demnächst
Matthias
Hallo Matthias,
Perl ist kein Kernthema.
Würde PHP als Kernthema gelten, wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)? Den Fragen im Forum und der allgemeinen weiten Verbreitung nach ist PHP deutlich besser als weiteres Kernthema zusätzlich zu HTML, CSS, JavaScript und den allgemeinen Grundlagen qualifiziert als Perl.
Gruß
Julius
Servus!
Hallo Matthias,
Perl ist kein Kernthema.
Würde PHP als Kernthema gelten,
Ja, wie Du schon schrubst, dreht sich im Forum viel um PHP.
wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)?
Immer zu! Wir haben uns drauf geeinigt, keine Dokumentation anzustreben (die gibt's schon anderswo), sondern uns auf Tutorials und Anwendungsartikel zu konzentrieren.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Wir haben uns drauf geeinigt, keine Dokumentation anzustreben (die gibt's schon anderswo)
Genau, da hatte ich schon mal mitbekommen (der als „problematische Seite“ verlinkte Perl-Artikel ist eine) und strebe ich nicht an.
sondern uns auf Tutorials und Anwendungsartikel zu konzentrieren.
Da will ich auch hin. Ich habe in an verschiedenen Stellen festgestellt, dass die PHP-Grundlagen-Vermittlung zu kurz kommt:
Ich habe mir folgendes Vorgehen vorgenommen, um eine PHP-Einführung (analog zu dem HTML-Einstiegs-Tutorial) zu erstellen:
Dann kommen davon losgelöste einzelne Tutorials oder Artikel zu:
mb_strlen()
, Normalisierung)Soweit zumindest der Plan...
Gruß
Julius
Aloha ;)
Würde PHP als Kernthema gelten, wenn sich im Wiki etwas am entsprechenden Bereich täte (ich habe eine Menge Notizen in der digitalen Schublade liegen)? Den Fragen im Forum und der allgemeinen weiten Verbreitung nach ist PHP deutlich besser als weiteres Kernthema zusätzlich zu HTML, CSS, JavaScript und den allgemeinen Grundlagen qualifiziert als Perl.
Jein. Ja, PHP ist sehr wichtig. Ja, PHP könnte ein Kernthema werden. Wir müssen nur auch aufpassen, dass wir uns nicht verzetteln. Im Bereich PHP gibt es schon eine sehr gut gepflegte Dokumentation in deutscher Übersetzung, der wir egal wie - Manpower, qualitativ, Aktualität - nichts entgegenzusetzen haben.
Selfhtml besetzt im Moment eine Nische, in der es wenig Konkurrenz gibt - als Webtech-Dokumentation in deutscher Sprache, die sich an Anfänger richtet. Hobby-Webseitenbastler zum Beispiel. Oder für Semi-Professionelle als Nachschlagwerk. In dieser Sparte haben wir nach wie vor Zugriffszahlen und eine große Relevanz - das ist der Grund, warum wir noch hier sind.
Wir müssen uns ein Stück weit dessen auch bewusst sein, was wir für ein Publikum bedienen. Professionellere Anwender suchen längst nicht mehr bei uns nach Rat - die sind sehr viel näher an den Quellen unterwegs. Was ja auch klar ist - es sind Profis mit viel Vorahnung, die mit Englisch und/oder Fachsprache kein Problem haben.
Ich finde es super, wenn Selfhtml weiter die Nische ausfüllt, die es ausfüllt. Zu dieser Nische gehört auch PHP. Ein wenig. In Form einzelner Tutorials oder einzelner How-To's in deutscher Sprache und an Anfänger gerichtet. Eine umfangreiche PHP-Sektion (wie wir sie für HTML/CSS/Javascript haben), die über diese Dinge hinausgeht, halte ich für Zielgruppen-verfehlt und unnötig - da gibt es php.net auf Deutsch und keinen Bedarf.
Verstehen wir uns da bitte nicht falsch - ich finde es gut, wenn das Wiki und das Projekt wächst. Deshalb sind wir hier. Wir sind nur auch in der Situation, dass wir nicht gerade an Personalüberschuss leiden. Deshalb ist es manchmal sicher angebracht, sich vorher zu überlegen, wo man am sinnvollsten Arbeit investieren kann.
Das war die nüchterne Analyse. Jetzt kommt die zweite Komponente: Wenns dein Steckenpferd sein soll und du da viel Lust drauf hast: Mach. Its a wiki. Und nichts ist stärker als intrinsische Motivation, ich will da niemanden ausbremsen 😉
TL;DR: Es gibt Bedenken, aber nur auf rationaler / projekt-strategischer Seite. Grundsätzlich profitiert das Projekt von jeder Form von qualitativ hochwertigem und in sich schlüssigem Inhalt![1]
Grüße,
RIDER
Nicht vergessen: Perl fliegt nicht vorrangig deshalb, weil es kein Kernthema ist, sondern weil der Perl-Bereich qualitativ nicht mehr mithalten kann - das Kernthema-Argument kommt erst dann zum Tragen, wenn es darum geht, ob man Kräfte mobil machen sollte um den Bereich zu sanieren, wenns keiner von sich aus tun will 😉 ↩︎
Hallo RIDER,
Jein. Ja, PHP ist sehr wichtig. Ja, PHP könnte ein Kernthema werden. Wir müssen nur auch aufpassen, dass wir uns nicht verzetteln. Im Bereich PHP gibt es schon eine sehr gut gepflegte Dokumentation in deutscher Übersetzung, der wir egal wie - Manpower, qualitativ, Aktualität - nichts entgegenzusetzen haben.
php.net will ich gar nicht nachbauen, eher das, was dort an Einsteiger-Freundlichen Informationen fehlt, nachreichen.
Selfhtml besetzt im Moment eine Nische, in der es wenig Konkurrenz gibt - als Webtech-Dokumentation in deutscher Sprache, die sich an Anfänger richtet.
In dieser Sparte haben wir nach wie vor Zugriffszahlen und eine große Relevanz - das ist der Grund, warum wir noch hier sind.
Und damit das auch so bleibt, halte ich etwas mehr Engagement im PHP-Bereich für nötig. Dort fehlen konsistente und (didaktisch und fachlich) hochwertige Beiträge für Einsteiger, wo ich hoffe, etwas leisten zu können.
Wir müssen uns ein Stück weit dessen auch bewusst sein, was wir für ein Publikum bedienen. Professionellere Anwender suchen längst nicht mehr bei uns nach Rat - die sind sehr viel näher an den Quellen unterwegs. Was ja auch klar ist - es sind Profis mit viel Vorahnung, die mit Englisch und/oder Fachsprache kein Problem haben.
Ich werde das so im Hinterkopf behalten und versuchen, wo immer möglich, Brücken zu den Quellen zu bauen. Für den Einsteig in ein bestimmtes, für den Betreffenden komplett neues Thema bzw. Themenbereich – da nehme ich mich nicht aus – ist eine Einführung in der Muttersprache oft einfacher als etwas in einer Fremdsprache. Alle Inhalte für Fortgeschrittene zu übersetzen, ist nicht leistbar und auch nicht nötig, weil irgendwann das Fachvokabular sitzt.
Ich finde es super, wenn Selfhtml weiter die Nische ausfüllt, die es ausfüllt. Zu dieser Nische gehört auch PHP. Ein wenig. In Form einzelner Tutorials oder einzelner How-To's in deutscher Sprache und an Anfänger gerichtet. Eine umfangreiche PHP-Sektion (wie wir sie für HTML/CSS/Javascript haben), die über diese Dinge hinausgeht, halte ich für Zielgruppen-verfehlt und unnötig - da gibt es php.net auf Deutsch und keinen Bedarf.
Ein Einstiegstutorial mit ein paar Ergänzungen wirds, keine Befehlsreferenz. Es geht mir auch darum, einen Weg aufzuzeigen, um PHP zu lernen. Vor allem sicher und dann Tipps zu geben, in welche Richtung man sich weiterentwickeln sollte und welche Möglichkeiten man hat (Objektorientierung, Unit-Tests).
Deshalb ist es manchmal sicher angebracht, sich vorher zu überlegen, wo man am sinnvollsten Arbeit investieren kann.
Meiner Meinung ist eine Investition in diesen Bereich durchaus sinnvoll, hier im Forum kommen oft grundlegende Fragen zu PHP bzw. Problembeschreibungen (Internationalisierung, Auslagern von Inhalten, Formulareingaben speichern, E-Mails versenden), die man in einem Tutorial über die Grundlagen von PHP abfrühstücken, oder die Grundlagen für eine Problemlösung zumindest im Wiki legen kann.
Grundsätzlich profitiert das Projekt von jeder Form von qualitativ hochwertigem und in sich schlüssigem Inhalt!
Die Schlüssigkeit ist im PHP-Bereich des Wikis bisher ein Problem, die vorhandenen Artikel sind nicht schlecht, aber ein ziemliches Durcheinander.
Nicht vergessen: Perl fliegt nicht vorrangig deshalb, weil es kein Kernthema ist, sondern weil der Perl-Bereich qualitativ nicht mehr mithalten kann
Beides hängt imho eng zusammen: Wäre Perl SELFHTML (bzw. im Web) genauso wichtig wie HTML, CSS und JavaScript, würde sich dessen schon jemand angenommen haben. Aber dass im Perl-Bereich in den letzten Jahren selbst kleinere Korrekturen von gelegentlich vorbei schauenden unterblieben, spricht für sich.
– das Kernthema-Argument kommt erst dann zum Tragen, wenn es darum geht, ob man Kräfte mobil machen sollte um den Bereich zu sanieren, wenns keiner von sich aus tun will 😉
Volle Zustimmung.
Gruß
Julius
Aloha ;)
Wie auch immer, ich bin nach wie vor dafür, die Perl-Teile einfach zu löschen. Zu wenig Mehrwert, zu viel Arbeit das auf einen neuen Stand zu bringen. Und Perl ist de facto irrelevant für die Web-Entwicklung.
Meine Stimme hast du dafür nach wie vor.
Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen - aber unterm Strich ist er sicher besser beraten, sich das Wissen woanders anzueignen als bei uns in hoffnungslos veralteter Form.
Das ist ja etwa so, wie wenn wir heutzutage ohne Hinweis auf dessen Überalterung ein HTML3.2-Tutorial bereitstellen würden als wenn das der Stand der Dinge wäre... Und genauso wie du sehe ich nach wie vor niemanden, der das verbessern kann - ich kann ja nichtmal Perl (und hab es auch nie vermisst) und vielen anderen potenziellen Autoren geht es sicher ähnlich.
Grüße,
RIDER
Hallo Camping_RIDER,
Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen -
Wir könnten die Seiten ins Museum verschieben, mit einem Warnhinweis versehen und für die Bearbeitung sperren.
Bis demnächst
Matthias
Servus!
Hallo Camping_RIDER,
Auch wenn es mir für den Perlentaucher, der sich grade daran weiterbildet, natürlich leid tut, ihm seine Arbeitsgrundlage zu entziehen -
Wir könnten die Seiten ins Museum verschieben, mit einem Warnhinweis versehen und für die Bearbeitung sperren.
Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:
Herzliche Grüße
Matthias Scharwies
Hallo Matthias Scharwies,
Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:
Das ist in der Tat noch besser.
Bis demnächst
Matthias
Hallo Matthias,
Oder wie bei den Feature-Artikeln auf die entsprechenden Seiten auf webarchive.org verweisen:
Das ist in der Tat noch besser.
Finde ich nicht. Wenn man sich auf fremde Plattformen verlässt, verliert man die Kontrolle über die eigenen Inhalte. Die Wayback-Maschine scheint gerade kaputt zu sein (Problem mit Mixed-Content) und hat außerdem nicht alle Seiten des alten sefhtml-Angebots gespeichert und verbockt die Zeichenkodierung. Beispiel: Astrid Steinmann: Ein Forum, ein Forum - ein Kφnigreich fόr ein Forum!
Das Schöne an archive.org ist natürlich, dass die dortigen Inhalte klar als archiviert und damit potenziell veraltet erkennbar sind. Ich finde es schade, wenn veraltete Inhalte nicht mehr verfügbar sind – Erschwert das Erforschen der Technik-Geschichte und das Wertschätzen der Gegenwart. Natürlich müssen Lernwillige auch davon abgehalten werden, diese veralteten Inhalte als aktuellen Stand der Dinge wahrzunehmen.
Gruß
Julius
Servus!
Das stimmt auch alles!
Herzliche Grüße
Matthias Scharwies
Hallo Julius,
Wenn man sich auf fremde Plattformen verlässt, verliert man die Kontrolle über die eigenen Inhalte.
In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.
Bis demnächst
Matthias
Hallo,
In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.
Statt zu depublizieren könnte man missionieren: Auf jeder Perl-Seite ein „So würde es in PHP aussehen“-Kästchen…
Gruß
Kalk
Hallo Tabellenkalk,
In dem Fall handelt es sich um eine Depublizierung. Wir wollen uns ja von diesen Inhalten distanzieren, bei uns soll es sie nicht mehr geben.
Statt zu depublizieren könnte man missionieren:
None of our business. IMHO.
LG,
CK
Hallo
Statt zu depublizieren könnte man missionieren: Auf jeder Perl-Seite ein „So würde es in PHP aussehen“-Kästchen…
Ich sehe, um bei deinem Bild zu bleiben, Religionskriege aufziehen.
Ein Python-Jünger — vielleicht war's auch ein Node-Adept — kommt daher, sieht das ‚„So würde es in PHP aussehen“-Kästchen‘ und wünscht das SelfHTML-Projektteam in in einen der tiefsten Schlünde der ewigen Vorhölle. Der neugewählte PHPapst hingegen verdammt in einer Erwiderung im schärfsten Ton der Empörung die Gesamtheit der Herätiker der Programmiererwelt. Zudem drückt er sein tiefstes Bedauern über das Hacksche Schisma aus.
Viel Spaß dabei. 😉
Tschö, Auge
Hallo,
Du hast sinnentstellend zitiert.
Für mich sieht es eher so aus, als ob pl die Aussage direkt auf Perl bezogen hat und nicht auf die Perl-„Dokumentation“ in unserem Wiki.
Gruß
Kalk
Hallo
Du hast sinnentstellend zitiert.
Für mich sieht es eher so aus, als ob pl die Aussage direkt auf Perl bezogen hat und nicht auf die Perl-„Dokumentation“ in unserem Wiki.
Meiner Meinung nach bezieht er sich auf den von Matthias genannten Zeitpunkt der Übertragung ins Wiki (2012) und darauf, dass wesentliche Änderungen an Perl schon lange vorher passiert sind, aber im SelfHTML-Wiki nicht berücksichtig werden. Das Weglassen des Teils von Mattias' Aussage, der besagt, dass es sich bei der Übertragung ins Wiki wohl nur eine Übernahme der bereits damals veralteten Inhalte der Doku handelte, ist mMn in der Tat sinnentstellend.
Tschö, Auge
Hallo,
Ah, ok, das ist auch denkbar. Wieder mal ein schönes Beispiel dafür, dass Kommunikation Glücksache ist.
Gruß
Kalk