Orlok: Array – Sprachelement und Standardobjekt

Hallo

Dem ein oder anderen wird vielleicht aufgefallen sein, dass es bezüglich der Dokumentation von Arrays im Wiki zuletzt einige Veränderungen gegeben hat, wobei insbesondere die am Wochenende von mir unter Mithilfe von Matthias Scharwies vollzogene Trennung zwischen dem Sprachelement Array und dem eingebauten Konstruktor Array zu nennen ist.

Anders als beispielsweise bei Funktionen, bei denen schon früher separate Artikel für das Sprachelement Funktion und den Konstruktor Function existierten, gab es diese Trennung bei Arrays nämlich bislang nicht. Das heißt, es gab nur den Artikel zu dem Standardobjekt, in dem jedoch eher der Objekttyp Array beschrieben wurde und nicht die gleichnamige Konstruktorfunktion.

Dabei wurde sowohl sprachlich als auch strukturell nur ungenügend zwischen Arrayinstanzen, dem eingebauten Konstruktor und Array.prototype unterschieden, sodass der Artikel in seiner früheren Form meiner Meinung nach zu Missverständnissen geradezu eingeladen hat.

Wir haben also nun in der Rubrik Sprachelemente einen neuen Artikel mit dem Namen Arrays angelegt und dort zunächst einmal den ursprünglich bei dem Standardobjekt Array hinterlegten Artikel hinkopiert, da dieser sich wie gesehen im Wesentlichen mit Arrays im Allgemeinen befasst und nicht in erster Linie mit dem eingebauten Konstruktor. – Auch wenn Arrays in den Code-Beispielen des Artikels vornehmlich mittels Array erzeugt wurden, statt wie es eigentlich zu empfehlen wäre, in Literalschreibweise. Hier hat Matthias Scharwies aber schon einige Verbesserungen vorgenommen, wofür ich ihm an dieser Stelle nochmal ausdrücklich danken möchte. ;-)

const good = [3.142];

const bad = new Array(3.142); // Range Error

Nachdem der Artikel, der sich mit Arrays im Allgemeinen befasst, nun also in die Rubrik Sprachelemente verlegt wurde, blieb natürlich auf der Seite zu dem Standardobjekt Array eine große Lücke. Wobei diese Lücke, inhaltlich betrachtet, genau genommen schon vorher existierte und sie nur durch die dort eigentlich nicht hingehörenden Ausführungen zum Sprachelement Array verdeckt wurde.

Darum habe ich nun einen entsprechenden Artikel geschrieben, der sich mit dem Standardobjekt Array befasst, wobei ich allerdings nicht nur Prosa hinzugefügt, sondern auch die Übersicht am Seitenanfang komplett überarbeitet habe. Die Übersicht entspricht nun dem Schema, das ich beim Schreiben des bis dato im Wiki nicht existierenden Artikels zum Konstruktor Object entwickelt hatte.

Ein allgemeines Konzept für die Übersichten am Seitenanfang bei der Dokumentation von eingebauten Objekten gab es bis zu diesem Zeitpunkt nämlich nicht, und ich war und bin der Ansicht, dass eine einheitliche und widererkennbare Übersicht am Seitenanfang der Nutzbarkeit und damit schlussendlich auch dem Verständnis von entsprechenden Artikeln zuträglich ist. Zumal ich es sehr praktisch finde, wenn bereits in der Einleitung die wichtigsten Daten und Verlinkungen aufgeführt sind, und die Angaben etwa zur Syntax, zu Attributen, gegebenenfalls zum Prototyp und zu Eigenschaften und Methoden, eigenen und vererbten, nach einem einheitlichen Schema präsentiert werden.

In diesem Zusammenhang möchte ich jedenfalls nochmals Matthias Apsel dafür danken, dass er meine zunächst mittels Inline Styles improvisierte Übersicht zu den Attributen von Eigenschaften in eine richtige Vorlage übertragen hat, die nunmehr auch für die Angabe der jeweiligen Syntax verwendet werden kann. Das einzige Manko daran ist, dass die Vorlage nur für Data Properties verwendet werden kann, nicht aber für Property Accessors, also Getter und Setter. Da letztere bei eingebauten Objekten aber ohnehin die absolute Ausnahme darstellen, sollte das kein großes Problem sein.

Schließlich habe ich bei bei der Übersicht zum Artikel Array auch die Liste der eigenen und vererbten Methoden einem Update unterzogen, sodass nunmehr jede eingebaute Methode zumindest aufgelistet ist, auch wenn für einige noch keine Artikel existieren, was unter anderem auch auf die vererbte Methode Array.prototype.fill zutraf. Für diese Methode habe ich allerdings einen Artikel geschrieben, ebenso wie für die eigenen Methoden Array.isArray und Array.of, die bislang ebenfalls noch keine Artikel hatten. Darüber hinaus habe ich noch einige Kleinigkeiten ergänzt und einige Absätze zu Array.length und zur Eigenschaft constructor von Array.prototype geschrieben, sowie hier und da einen Link gesetzt und die ein oder andere missverständliche oder falsche Formulierung korrigiert.

Jedenfalls, auch wenn immernoch viel fehlt und bestehende Artikel überarbeitet werden müssen, denke ich doch, dass wir hier einiges zur Verbesserung des Wikis beigetragen haben. :-)

Also danke für euer Interesse und beste Grüße,

Orlok

akzeptierte Antworten

  1. Lieber Orlok,

    Lob (ein dickes!) und Begeisterung von mir!

    Liebe Grüße,

    Felix Riesterer.

    1. Hallo @Felix Riesterer

      Lob (ein dickes!) und Begeisterung von mir!

      Danke, das hört man gerne. :-)

      Es fällt mir in der Tat nicht immer leicht, mich für die Arbeit im Wiki zu motivieren, da man hierbei in der Regel keinerlei Rückmeldung von den Lesern bekommt. Deshalb dokumentiere ich auch regelmäßig meine Beiträge zum Wiki hier im Meta-Forum. ;-)

      So kann ich zum Beispiel heute berichten, dass eine weitere Lücke geschlossen wurde, denn nachdem ich in einigen Forumsbeiträgen die Methode bereits erwähnte, ein dazugehöriger Artikel im Wiki jedoch noch nicht existierte, habe ich nun einen Artikel für Array.prototype.includes geschrieben.

      const ducks = ['tick', 'trick', 'track'];
      
      console.log(ducks.includes('trick')); // true
      

      Dabei handelt es sich übrigens um die zuletzt standardisierte Methode von Array.prototype, die erst seit ECMAScript 2016 Teil der Sprache ist. Entsprechend wurde includes auch erst von wenigen Browsern implementiert, weshalb ich dafür ein Polyfill gebastelt und dem Artikel hinzugefügt habe.

      Also, nochmals Dank und beste Grüße,

      Orlok

      1. Lieber Orlok,

        Lob (ein dickes!) und Begeisterung von mir!

        Danke, das hört man gerne. :-)

        drum schrieb ich's ja. ;-)

        in der Regel keinerlei Rückmeldung von den Lesern bekommt. Deshalb dokumentiere ich auch regelmäßig meine Beiträge zum Wiki hier im Meta-Forum. ;-)

        Finde ich absolut legitim. Auch wenn es auf den ersten Blick wie "fishing for compliments" erscheinen mag, so bietet jede dieser Meldungen eine Gelegenheit für (hoffentlich konstruktive) Kritik. Und das soll ja hier und nicht auf den Diskussionsseiten im Wiki geschehen.

        Wenn wir schon bei Kritik sind: Ist es für unbedarftere Leser wünschenswert, anschaulichere Beispiele zu erstellen? Gerade diejenigen, die unser Wiki zum Lernen und weniger zum Nachschlagen brauchen, schauen sicher seltener in die Browserkonsole. Gerade für includes böte es sich an zu prüfen, ob ein Affe Bananen und Seetang frisst:

        const Affenfutter = [
            "Banane", "Samen"
        ];
        
        alert(
            "Affen fressen "
            + (Affenfutter.includes("Banane") ? "gerne" : "keine")
            + " Bananen."
        );
        alert(
            "Affen fressen "
            + (Affenfutter.includes("Seetang") ? "gerne" : "keinen")
            + " Seetang."
        );
        

        Da an anderer Stelle ausdrücklich davor gewarnt wird, in Sprachelemente verändernd einzugreifen, böte sich hier ein kurzer Absatz an, warum dieses Polyfill absichtlich doch dieses tut, und warum dieses Vorgehen nicht nur sinnvoll sondern wichtig ist.

        Liebe Grüße,

        Felix Riesterer.

        1. Hallo Felix

          Finde ich absolut legitim. Auch wenn es auf den ersten Blick wie "fishing for compliments" erscheinen mag, so bietet jede dieser Meldungen eine Gelegenheit für (hoffentlich konstruktive) Kritik. Und das soll ja hier und nicht auf den Diskussionsseiten im Wiki geschehen.

          Sehe ich auch so. Ich denke, hiervon profitieren beide Seiten: Ich selbst, weil ich entweder positives Feedback bekomme das mich motiviert, oder weil jemand wie du hier konstruktive Kritik äußert, die mich bessere Artikel schreiben lässt. Und die Leser, die einerseits mitbekommen was sich im Wiki so tut und die andererseits die Gelegenheit bekommen, dazu Stellung zu nehmen.

          Wenn wir schon bei Kritik sind: Ist es für unbedarftere Leser wünschenswert, anschaulichere Beispiele zu erstellen?

          Klar ist es das! :-D

          Aber es ist gar nicht so leicht, sich für jede Begebenheit ein schönes, anschauliches Beispiel auszudenken. Ich habe in den letzten Wochen diverse Artikel geschrieben und dabei weit über hundert verschiedene Codebeispiele eingebaut, wie ein kurzes Überfliegen der besagten Artikel gerade ergeben hat. Wenn ich mir mit den Beispielen noch mehr Zeit genommen hätte, dann gäbe es jetzt sicher den ein oder anderen Artikel weniger. Und damit die ein oder andere inhaltliche Lücke im Wiki mehr. ;-)

          Aber es ist nicht nur eine Frage des Zeitaufwands, sondern es ist auch immer zu berücksichtigen, welchen Zweck ein bestimmtes Beispiel erfüllen soll. Sprich, wenn es das Ziel ist irgendeine Syntax zu veranschaulichen, dann ist es meiner Meinung nach eher kontraproduktiv, wenn das Ganze in einem zu opulenten Kontext präsentiert wird. Da ist es glaube ich besser, sich auf das Wesentliche zu beschränken.

          Denn darüber hinaus ist schließlich auch immer zu berücksichtigen, dass man ja nie weiß, welches Vorwissen der Leser oder die Leserin besitzt. Schreibt man also ein ausführlicheres, vielleicht auch praxisnäheres Beispiel, dann lässt sich das Risiko kaum vermeiden, Sprachmittel zu verwenden, mit denen der oder die Lesende womöglich nicht vertraut ist. Also muss man dann im Begleittext noch weitere Einzelheiten des Beispiels erklären oder zumindest Erklärungen verlinken, was aber alles wieder vom eigentlichen Thema ablenkt. Und natürlich auch wieder Zeit kostet, die an anderer Stelle vielleicht besser investiert wäre.

          Prinzipiell gebe ich dir also auf jeden Fall recht, dass anschauliche und ausdrucksstarke Beispiele eine gute Sache sind und wir Autoren uns darum bemühen sollten solche Beispiele zu erstellen, aber ich mag eben auch zu bedenken geben, dass die Lücken immer noch groß und die Autoren wenige sind, und dass diese Autoren auch nicht unendlich viel Zeit investieren können um die Lücken zu schließen, weshalb es vielleicht manchmal auch einfach eine aus der Not heraus geborene Entscheidung pro Inhalt und contra Form ist, wenn man nur zeigt, was wann und unter welchen Umständen ausgegeben wird.

          Gerade diejenigen, die unser Wiki zum Lernen und weniger zum Nachschlagen brauchen, schauen sicher seltener in die Browserkonsole. Gerade für includes böte es sich an zu prüfen, ob ein Affe Bananen und Seetang frisst:

          const Affenfutter = [
              "Banane", "Samen"
          ];
          
          alert(
              "Affen fressen "
              + (Affenfutter.includes("Banane") ? "gerne" : "keine")
              + " Bananen."
          );
          alert(
              "Affen fressen "
              + (Affenfutter.includes("Seetang") ? "gerne" : "keinen")
              + " Seetang."
          );
          

          Bevor ich näher auf diesen Punkt eingehe – bitte verzeih’ mir – kann ich nicht umhin, etwas aus einem deiner früheren Postings zu zitieren. :-D

          Aus meiner Sicht ist window.alert grundsätzlich zu bekämpfen.

          Mein Credo: Anfängern ist alert als giftig und strengstens zu vermeiden abzuempfehlen.

          Ich weiß, ich weiß, das war gemein. ;-)

          Aber eigentlich finde ich, dass du damit recht hattest, denn gerade Anfänger, die das Wiki zum Lernen benutzen, sollten so früh wie möglich lernen, dass es eine Konsole gibt und wie und wofür man sie verwenden kann. Einen Artikel der sich damit befasst gibt es ja. Dieser sollte am besten in jedem Artikel der in den Beispielen die Konsole verwendet auch verlinkt werden. Dass ich das bislang nicht konsequent getan habe ist ein Fehler.

          Darüber hinaus möchte ich jedoch zu bedenken geben, dass ich in meinen Beispielen durchaus versuche, auf die üblichen Verdächtigen foo, bar und baz zu verzichten. ;-)

          const jekyll = { };
           
          const hyde = Object(jekyll);
           
          console.log(jekyll === hyde); // true
          

          Zugegeben, die meisten meiner Beispiele sind nur mäßig originell, wie dieses Beispiel aus meinem Artikel zum Konstruktor Object. Aber wie ich schon sagte, ist die Frage auch immer wieviel Zeit man sich dafür nehmen kann und will, um sich ein besseres Beispiel auszudenken. Ich habe über manchen Beispielen wirklich lange gebrütet und dann ein schlechtes Gewissen bekommen, weil ich das Gefühl hatte, ich hätte die Zeit auch produktiver Nutzen und vielleicht die eine oder andere wirklich gravierende inhaltliche Lücke im Wiki schließen können.

          Davon abgesehen, habe ich mir angewöhnt die Codebeispiele grundsätzlich in Englisch zu verfassen, dafür aber im Fließtext nach Möglichkeit keine englischen sondern deutsche Begriffe zu verwenden, wobei ich dann oft noch die englische Übersetzung in Klammern dahinter setze. Ich meine, natürlich ist es kein Fehler, in Codebeispielen deutsche Worte für Bezeichner zu verwenden, aber ich finde es kann nicht schaden, der englischen Sprache hier zumindest in diesem Kontext etwas Raum zu geben, zumal jeder, der sich vom totalen Anfänger in diesem Bereich weiterentwickeln möchte, früher oder später nicht umhinkommt, auch Texte und Code in dieser Sprache zu lesen. Aber diese Entscheidung, Code grundsätzlich in Englisch zu verfassen, möchte ich natürlich niemandem aufzwingen.

          Und um noch etwas zu der von dir verwendeten Technik zu sagen: Strinkkonkatenation wie in deinem Beispiel ist sowas von ECMAScript 5! ;-)

          const Affenfutter = ['Banane', 'Samen'];
          
          console.info(`Affen fressen ${
            Affenfutter.includes('Banane') ? 'gerne' : 'keine'
          } Bananen.`);
          
          console.info(`Affen fressen ${
            Affenfutter.includes('Seetang') ? 'gerne' : 'keinen'
          } Seetang.`);
          

          Genauso wie der Syntaxhighlighter hier im Forum, oder wird das bei irgendwem richtig angezeigt? :-D

          Naja, aber selbst ohne Template Strings, wäre eine Variante mit Array.prototype.join doch eher zu empfehlen. Aber das ist im Moment ohnehin ein großes Problem, da in ECMAScript 6 die Antworten auf viele Fragen nach der best practice anders ausfallen, die entsprechende Syntax in dieser Übergangsphase aber oft noch nicht zufriedenstellend unterstützt wird.

          Und um nochmal auf einen Satz von dir zurückzukommen:

          Gerade diejenigen, die unser Wiki zum Lernen und weniger zum Nachschlagen brauchen

          Ich denke, gerade die Teile des Wikis in denen ich mich bislang eingebracht habe betreffen ja eher die technische Dokumentation und weniger Tutorials für Anfänger. Ich denke, da ist es dann vielleicht auch eher verzeihlich, wenn die Beispiele ein wenig sachlicher und abstrakter sind, als es in einem Anfängertutorial angebracht wäre.

          Da an anderer Stelle ausdrücklich davor gewarnt wird, in Sprachelemente verändernd einzugreifen, böte sich hier ein kurzer Absatz an, warum dieses Polyfill absichtlich doch dieses tut, und warum dieses Vorgehen nicht nur sinnvoll sondern wichtig ist.

          Da hast du allerdings recht. – Werde sehen, dass ich die Info hinzufüge.

          Jedenfalls, wie dem auch sei, möchte ich mich für deine konstruktive Kritik bedanken! :-)

          Viele Grüße,

          Orlok

          1. Lieber Orlok,

            Wenn wir schon bei Kritik sind: Ist es für unbedarftere Leser wünschenswert, anschaulichere Beispiele zu erstellen?

            Klar ist es das! :-D

            prima!

            Wenn ich mir mit den Beispielen noch mehr Zeit genommen hätte, dann gäbe es jetzt sicher den ein oder anderen Artikel weniger. Und damit die ein oder andere inhaltliche Lücke im Wiki mehr. ;-)

            Dieses Argument lässt sich nicht widerlegen. Auch war es nicht meine Absicht, dass Du selbst anschaulichere Beispiele erstellst, sondern Deine Bereitschaft zum Abändern der vorhandenen Beispiele hin zu für Lernende anschaulichere abzufragen. Jetzt, da ich verstanden habe, dass Du prinzipiell nicht dagegen bist, kann man Dir diese Arbeit ja abnehmen. Ist ja ein Wiki.

            Aber es ist nicht nur eine Frage des Zeitaufwands, sondern es ist auch immer zu berücksichtigen, welchen Zweck ein bestimmtes Beispiel erfüllen soll. Sprich, wenn es das Ziel ist irgendeine Syntax zu veranschaulichen, dann ist es meiner Meinung nach eher kontraproduktiv, wenn das Ganze in einem zu opulenten Kontext präsentiert wird. Da ist es glaube ich besser, sich auf das Wesentliche zu beschränken.

            Das ist sicherlich richtig. Und wenn syntaktische Extras im Code sind, kann man diese ja unter dem Code-Beispiel ansprechen und auf die jeweiligen Erläuterungen dazu im Wiki verlinken.

            Denn darüber hinaus ist schließlich auch immer zu berücksichtigen, dass man ja nie weiß, welches Vorwissen der Leser oder die Leserin besitzt. Schreibt man also ein ausführlicheres, vielleicht auch praxisnäheres Beispiel, dann lässt sich das Risiko kaum vermeiden, Sprachmittel zu verwenden, mit denen der oder die Lesende womöglich nicht vertraut ist. Also muss man dann im Begleittext noch weitere Einzelheiten des Beispiels erklären oder zumindest Erklärungen verlinken, was aber alles wieder vom eigentlichen Thema ablenkt. Und natürlich auch wieder Zeit kostet, die an anderer Stelle vielleicht besser investiert wäre.

            Damit soll es nicht (unbedingt) in Deinen Aufgabenbereich fallen. Jetzt, da Du einen Artikel erstellt hast, kann man ihn "verschönern". Da Du hier ins Meta-Forum gehst, um über diesen Artikel zu berichten, kann man gleich hier an Ort und Stelle über ein "schöneres" Beispiel diskutieren.

            const Affenfutter = [
                "Banane", "Samen"
            ];
            
            alert(
                "Affen fressen "
                + (Affenfutter.includes("Banane") ? "gerne" : "keine")
                + " Bananen."
            );
            alert(
                "Affen fressen "
                + (Affenfutter.includes("Seetang") ? "gerne" : "keinen")
                + " Seetang."
            );
            

            Bevor ich näher auf diesen Punkt eingehe – bitte verzeih’ mir – kann ich nicht umhin, etwas aus einem deiner früheren Postings zu zitieren. :-D

            Aus meiner Sicht ist window.alert grundsätzlich zu bekämpfen.

            Mein Credo: Anfängern ist alert als giftig und strengstens zu vermeiden abzuempfehlen.

            Ich weiß, ich weiß, das war gemein. ;-)

            Nein, das war es nicht. Mein Beispiel war nicht genügend durchdacht und Wiki-fertig. Ist es nicht gut, dass ich es nicht sofort im Wiki eingesetzt, sondern erst hier zur Diskussion gestellt habe? So konntest Du als ursprünglicher Autor des Wiki-Artikels Deine Sichtweise anbringen und mein Beispiel zur Verbesserung vorschlagen.

            Aber eigentlich finde ich, dass du damit recht hattest, denn gerade Anfänger, die das Wiki zum Lernen benutzen, sollten so früh wie möglich lernen, dass es eine Konsole gibt und wie und wofür man sie verwenden kann. Einen Artikel der sich damit befasst gibt es ja. Dieser sollte am besten in jedem Artikel der in den Beispielen die Konsole verwendet auch verlinkt werden. Dass ich das bislang nicht konsequent getan habe ist ein Fehler.

            Ersetze "Fehler" mit "Unvollständigkeit". Das klingt weniger schlimm. Vor allem am Anfang des Artikels könnte ein Hinweis stehen, dass viele der Code-Beispiele die Konsole des Browsers zur Ausgabe nutzen. Fertig.

            Darüber hinaus möchte ich jedoch zu bedenken geben, dass ich in meinen Beispielen durchaus versuche, auf die üblichen Verdächtigen foo, bar und baz zu verzichten. ;-)

            +1

            Davon abgesehen, habe ich mir angewöhnt die Codebeispiele grundsätzlich in Englisch zu verfassen, dafür aber im Fließtext nach Möglichkeit keine englischen sondern deutsche Begriffe zu verwenden, wobei ich dann oft noch die englische Übersetzung in Klammern dahinter setze.

            Das finde ich sehr sinnvoll. Auch ich habe mir angewöhnt meinen Code mit englischen Bezeichnern zu versehen (das war nicht immer so). Man darf nicht ausser Acht lassen, dass Software in diesen Webtechnologien grundsätzlich quelloffen ist (von obfuskiertem Code einmal abgesehen) und im internationalen Raum erreichbar ist. Insofern ist es der Natur der Sache geschuldet, wenn man sich auf englische Namen für Bezeichner besinnt.

            Aber diese Entscheidung, Code grundsätzlich in Englisch zu verfassen, möchte ich natürlich niemandem aufzwingen.

            Aber man kann es anregen, da es einen Sinn hat.

            Und um noch etwas zu der von dir verwendeten Technik zu sagen: Strinkkonkatenation wie in deinem Beispiel ist sowas von ECMAScript 5! ;-)

            const Affenfutter = ['Banane', 'Samen'];
            
            console.info(`Affen fressen ${
              Affenfutter.includes('Banane') ? 'gerne' : 'keine'
            } Bananen.`);
            
            console.info(`Affen fressen ${
              Affenfutter.includes('Seetang') ? 'gerne' : 'keinen'
            } Seetang.`);
            

            Jau. Nu isses echt mal schöner, Mann. Aber irgendwie kommt mir das ${...} wie Bash-Syntax vor. Sicherlich hat es da auch seinen Ursprung. Und was das Code-Beispiel angeht, so hätte ich lieber eine Funktion wie sprintf in PHP. Dass es dieses in JavaScript noch nicht als Standard-Stringmethode gibt, will ich nicht einsehen. Momentan muss man sich mit einer zusätzlichen Bibliothek behelfen (sprintf für JavaScript). Selbst die Konsole kennt Parameterersetzung in Strings!

            Aber das ist im Moment ohnehin ein großes Problem, da in ECMAScript 6 die Antworten auf viele Fragen nach der best practice anders ausfallen, die entsprechende Syntax in dieser Übergangsphase aber oft noch nicht zufriedenstellend unterstützt wird.

            Es gäbe ja längst schon ein bewährtes Konzept... sprintf

            Ich denke, gerade die Teile des Wikis in denen ich mich bislang eingebracht habe betreffen ja eher die technische Dokumentation und weniger Tutorials für Anfänger. Ich denke, da ist es dann vielleicht auch eher verzeihlich, wenn die Beispiele ein wenig sachlicher und abstrakter sind, als es in einem Anfängertutorial angebracht wäre.

            Schon OK. Ich wollte in dieser Diskussion auch beispielhaft ausprobieren, inwiefern man Deine Arbeit ergänzend unterstützen kann, welche technischen Möglichkeiten sich bieten (auch anhand Deiner Einstellungen zur Thematik), und wie sich das Prinzip bewährt, dass wir Diskussionen zu Wiki-Seiten eben nicht dort, sondern in diesem Forum führen.

            Da an anderer Stelle ausdrücklich davor gewarnt wird, in Sprachelemente verändernd einzugreifen, böte sich hier ein kurzer Absatz an, warum dieses Polyfill absichtlich doch dieses tut, und warum dieses Vorgehen nicht nur sinnvoll sondern wichtig ist.

            Da hast du allerdings recht. – Werde sehen, dass ich die Info hinzufüge.

            Dann lohnt vielleicht ein eher allgemein gehaltener Artikel zu "Polyfill"? Momentan haben wir nur etwas zu Polyfill im Glossar.

            Jedenfalls, wie dem auch sei, möchte ich mich für deine konstruktive Kritik bedanken! :-)

            Herzlich gerne!

            Liebe Grüße,

            Felix Riesterer.

            1. Hallo ihr beiden Fleißigen :)

              Gibt es eigentlich schon einen Artikel zu String Templates? Gefunden habe ich keinen...

              Gruß Rolf

              1. Hallo Rolf b,

                Hallo ihr beiden Fleißigen :)

                +1 ;-)

                Gibt es eigentlich schon einen Artikel zu String Templates? Gefunden habe ich keinen...

                ndiw ;-)

                Bis demnächst
                Matthias

                --
                Wenn eine Idee nicht zuerst absurd erscheint, taugt sie nichts. (Albert Einstein)
        2. Hallo Felix,

          in der Regel keinerlei Rückmeldung von den Lesern bekommt. Deshalb dokumentiere ich auch regelmäßig meine Beiträge zum Wiki hier im Meta-Forum. ;-)

          Finde ich absolut legitim.

          Ich auch.

          Auch wenn es auf den ersten Blick wie "fishing for compliments" erscheinen mag, […]

          Ich halte „fishing for compliments“ nicht für verwerflich. Wir arbeiten hier alle ohne pekuniäre Entlohnung, das heißt, dass dieser Faktor als extrinsische Motivation weg fällt. Rein intrinsisch kann ein derart hohes Level an Motivation oft nicht lange gehalten werden, es muss also eine Alternative zu der Entlohnung via Geld her. Das ist in unserem Bereich nunmal Aufmerksamkeit und Lob. Und da im Internet viel zu wenig gelobt wird, muss das in gewissem Maße eingefordert werden – fishing for compliments.

          In dem Sinne: danke für deine Arbeit, @Orlok, bitte mach weiter so. Ich finde das gut, und das kommt von Herzen!

          LG,
          CK

  2. Hallo Orlok,

    da ich gerade am Basisartikel Objekte und Eigenschaften dran bin, bin ich automatisch auf die Abgrenzung Objekt-Array gestoßen und damit auch wieder auf deinen Array-Artikel. Ich finde ihn grundsätzlich gut, möchte aber ein paar Punkte anmerken.

    1. Indexe Ich habe die Information nicht gesehen, dass ein echter Array-Index ein Integer-Wert ist (Wert 0 bis 2^32-1). Sie gehört IMO in den Prosa-Artikel und auch in den Referenz-Artikel. Zuweisungen an Indexe in diesem Bereich aktualisieren automatisch die length-Eigenschaft (sprich: Schreibe ich einen Wert auf arr[i] und i>=arr.length, wird arr.length=i+1 gesetzt). Verwendet man einen Index, der diesen Zahlenraum verlässt, so wird er Wert zwar geschrieben, erzeugt aber "nur" ein Property von arr, ohne length zu verändern.

    2. Array(n) vs Array(x,y,z) Ein Ugly Part von JavaScript. In der Referenz hast Du es Oma-kompatibel erläutert. Vielleicht sollte man es dort kompakter darstellen und die Oma-Version in den Prosa-Artikel stellen. Und vielleicht mit der Nennung beider Aufrufformen beginnen und betonen, dass die Einparameter-Version unbedingt eine Array-Länge und keine Array-Werte erwartet, weshalb alles, was außerhalb der gültigen Indexwerte liegt, zu einer Fehlermeldung führt. Weiß nicht. Habe es noch nicht zu formulieren versucht.

    3. Assoziative Arrays Den Abschnitt finde ich schwer verständlich. Ich will nicht einfach nach Gutdünken dran rumbasteln - daher hier meine Anregungen:

    • Es müsste klargestellt werden, dass das, was hier als assoziatives Array gezeigt wird, eben kein Array ist, sondern ein allgemeines Objekt.
    • Normale Objekte als Beispiel für assoziative Arrays zu bringen, halte ich für nicht so gut. Damit förderst Du unnötig die Kritik, die im Objekte-Artikel über AAs geäußert wird. AAs sind sinnvoll, wenn die Schlüssel erst zur Laufzeit bekannt werden, also z.B. wenn man ein Dictionary oder eine Lookup-Tabelle braucht.
    1. Literalnotation eines Array of Objects Es ist gut, sowas zu erklären. Aber als Nachklapperer zu AAs geht es unter. Vielleicht verwendest Du es einfach direkt in deinem AA Beispiel und erläuterst kurz, was das tut?

    Rolf

    1. Hallo Rolf

      da ich gerade am Basisartikel Objekte und Eigenschaften dran bin, bin ich automatisch auf die Abgrenzung Objekt-Array gestoßen und damit auch wieder auf deinen Array-Artikel. Ich finde ihn grundsätzlich gut, möchte aber ein paar Punkte anmerken.

      1. Indexe Ich habe die Information nicht gesehen, dass ein echter Array-Index ein Integer-Wert ist (Wert 0 bis 2^32-1). Sie gehört IMO in den Prosa-Artikel und auch in den Referenz-Artikel.

      Zunächst einmal: Ja, du hast recht, diese Information fehlt tatsächlich. Allerdings finde ich die Formulierung Prosa versus Referenz ein wenig missverständlich; Der unter Sprachmittel einsortierte Artikel [JavaScript/Array] soll in erster Linie den Objekt-Typ Array zum Gegenstand haben. Das heißt, dieser Artikel ist grundsätzlich der richtige Ort, um die Eigenschaft length von Arrays abzuhandeln.

      Der unter Standardobjekte einsortierte Artikel [JavaScript/Objekte/Array] hingegen enthält die Beschreibung des Konstruktors Array, der zwar auch eine Eigenschaft length besitzt, die aber nur die Anzahl der formalen Parameter widergibt. Alles was im Zusammenhang mit Arrays, also den Instanzen von Array zu sagen ist, sollte in den Artikel unter der Rubrik Sprachmittel geschrieben werden, aber eben gerade nicht in den Artikel zu der eingebauten Funktion Array, denn genau diese Vermischung von unterschiedlichen Inhalten aufzuheben war das Ziel der ganzen Aktion.

      1. Array(n) vs Array(x,y,z) Ein Ugly Part von JavaScript. In der Referenz hast Du es Oma-kompatibel erläutert. Vielleicht sollte man es dort kompakter darstellen und die Oma-Version in den Prosa-Artikel stellen.

      Ich habe es in dem durchaus nicht übermäßig langen Artikel zum Konstruktor Array in meiner Ansicht nach absolut verhältnismäßiger Art und Weise beschrieben. Dass der eingebaute Konstruktor Array ein einzelnes Argument vom Datentyp Number versucht als Wert für die Eigenschaft length des erzeugten Arrays zu setzen, ist einer der wesentlichen Punkte bei der Beschreibung des Verhaltens dieses Standardobjektes. Ich sehe nicht, warum das in diesem Artikel kompakter dargestellt werden sollte.

      Was den Artikel zum Sprachmittel Array angeht, sollte dort in den Beispielen nach Möglichkeit fast gänzlich auf den Konstruktor Array zur Erstellung von Arrays verzichtet werden. Aber natürlich sollte dort trotzdem gezeigt werden wie es geht. Dabei kann dann, in der Tat in aller Kürze, auf die von dir angesprochene Besonderheit eingegangen und dazu der Artikel zum Konstruktor Array verlinkt werden.

      1. Assoziative Arrays Den Abschnitt finde ich schwer verständlich. Ich will nicht einfach nach Gutdünken dran rumbasteln - daher hier meine Anregungen:
      • Es müsste klargestellt werden, dass das, was hier als assoziatives Array gezeigt wird, eben kein Array ist, sondern ein allgemeines Objekt.
      • Normale Objekte als Beispiel für assoziative Arrays zu bringen, halte ich für nicht so gut. Damit förderst Du unnötig die Kritik, die im Objekte-Artikel über AAs geäußert wird. AAs sind sinnvoll, wenn die Schlüssel erst zur Laufzeit bekannt werden, also z.B. wenn man ein Dictionary oder eine Lookup-Tabelle braucht.
      1. Literalnotation eines Array of Objects Es ist gut, sowas zu erklären. Aber als Nachklapperer zu AAs geht es unter. Vielleicht verwendest Du es einfach direkt in deinem AA Beispiel und erläuterst kurz, was das tut?

      Dass der Artikel, der unter Sprachmittel einsortiert ist, stark verbesserungswürdig ist, brauchst du mir nicht zu sagen. Zu diesem Artikel habe ich übrigens inhaltlich gar nichts beigetragen, sondern das ist im Wesentlichen das, was vorher unter Standardobjekte einsortiert war. Plus einige Veränderungen an den Beispielen durch Matthias Scharwies, wenn ich das richtig mitbekommen habe.

      Ich hatte mir eigentlich vorgenommen, sobald ich mit meinen anderen Baustellen soweit fertig bin, diesen Artikel komplett neu zu schreiben, weil ich ebenso wie du der Ansicht bin, dass hier einiges zu verbessern und hinzuzufügen ist. – Allerdings kann das durchaus noch etwas dauern …

      Gruß,

      Orlok

      1. Hallo Orlok,

        da hast Du recht mit Array.length - natürlich meinte ich Array.prototype.length.

        Vielleicht hatte ich ja die Intention der beiden Artikelbereiche falsch verstanden. Meine Auffassung wäre diese: JavaScript/Array soll einem Einsteiger klar machen, was ein Array ist und wie man damit umgeht. Und zwar nicht als knallharte Auflistung von Features, sondern als lesbaren Text mit didaktischem Anspruch. Daher meine Bezeichnung "Prosa". Im Artikel JavaScript/Objekte/Array sehe ich zweierlei: eine präzise und vollständige Beschreibung des Array-Konstruktors für Leute, die JavaScript/Arrays verstanden haben, sowie eine Verteilerseite auf die diversen Artikel unterhalb von JavaScript/Objekte/Array, die die Properties von Array und Array.prototype behandeln. Deswegen kam ich auf den Vorschlag, die Abstraktionslatte hier etwas höher zu legen.

        Aber das ist hier nicht mein Wiki, und wenn ihr das anders gestalten wollt werde ich mich natürlich daran orientieren. Daher bitte nicht böse sein wenn meine Vorschläge nicht zu eurem Konzept passen. Ich lerne noch :)

        Gruß Rolf

        1. Hallo Rolf

          da hast Du recht mit Array.length - natürlich meinte ich Array.prototype.length.

          Ich denke, eigentlich meintest du die Eigenschaft length bei Arrays. Obwohl die spezielle Eigenschaft Array.prototype.length natürlich dazuzählt, da es sich bei dem Objekt, welches über Array.prototype referenziert wird, ja auch um ein Array handelt.

          Vielleicht hatte ich ja die Intention der beiden Artikelbereiche falsch verstanden. Meine Auffassung wäre diese: JavaScript/Array soll einem Einsteiger klar machen, was ein Array ist und wie man damit umgeht. Und zwar nicht als knallharte Auflistung von Features, sondern als lesbaren Text mit didaktischem Anspruch. Daher meine Bezeichnung "Prosa". Im Artikel JavaScript/Objekte/Array sehe ich zweierlei: eine präzise und vollständige Beschreibung des Array-Konstruktors für Leute, die JavaScript/Arrays verstanden haben, sowie eine Verteilerseite auf die diversen Artikel unterhalb von JavaScript/Objekte/Array, die die Properties von Array und Array.prototype behandeln. Deswegen kam ich auf den Vorschlag, die Abstraktionslatte hier etwas höher zu legen.

          Grundsätzlich sind sowohl der Artikel zum Sprachelement Array, als auch der Artikel zum Standardobjekt Array Teil der Dokumentation der Sprache, und an beide Artikel sollte meiner Meinung nach derselbe Anspruch gestellt werden, einerseits verständlich geschrieben zu sein und andererseits die technischen Hintergründe möglichst umfassend und präzise zu beschreiben. Darüber hinaus wäre es aber sicher keine schlechte Sache, wenn es im Bereich [JavaScript/Tutorials] noch einen Artikel gäbe, der sich dem Thema in besonders für Anfänger geeigneter Weise annehmen würde. Dort gibt es ja sogar eine eigene Rubrik, welche die Überschrift für Anfänger hat. Aber selbst dann, wenn es einen solchen speziell an Anfänger gerichteten Artikel zu dem Thema gäbe, hieße das wie gesagt nicht, dass im Gegenzug die verschiedenen Artikel der Dokumentation sich ausschließlich an Fortgeschrittene und Profis richten würden. Auch diese Artikel sollten so geschrieben sein, dass Leser ohne großes Vorwissen damit etwas anfangen können, soweit das im Einzelfall möglich und angemessen ist.

          Aber das ist hier nicht mein Wiki, und wenn ihr das anders gestalten wollt werde ich mich natürlich daran orientieren. Daher bitte nicht böse sein wenn meine Vorschläge nicht zu eurem Konzept passen. Ich lerne noch :)

          Entschuldige bitte, falls das irgendwie so rübergekommen sein sollte, aber ich bin dir definitiv nicht böse. Ganz im Gegenteil, ich freue mich sehr über dein Engagement und auch darüber, dass du dich in die Diskussion hier einbringst. Man hat mir zwar vor einiger Zeit die Leitung dieser Sektion des Wikis angetragen, aber das bedeutet natürlich nicht, dass die Konzepte wie ich sie darstelle unhinterfragt befolgt werden müssten. Sprich, wenn jemand einen besseren Vorschlag dafür hat, wie irgendein Problem zu lösen ist, dann werde ich ganz bestimmt nicht dagegen votieren, nur weil der Vorschlag nicht von mir kommt. – Es ist also auch nicht mein Wiki, sondern es ist unser Wiki. ;-)

          Gruß,

          Orlok

          1. Hallo Orlok,

            da ich noch sehr neu bin, bin ich naturgemäß sehr vorsichtig was menschlichen Umgang angeht. Die gegenseitige Zusicherung, dass man sich nicht irgendwas übelnimmt, ist mir deshalb sehr wichtig. Danke für deine Antwort darauf.

            Nochmal zum Thema :)

            (1) length bei Arrays ist tatsächlich sehr verwirrend. Es gibt Array.length, konstant 1, dann Array.prototype.length, konstant 0, und dann hat jedes Array ein eigenes, ungeerbtes length-Property mit der realen Länge. Da war ich im Irrtum, ich dachte irgendwie, dass die length Eigenschaft eines Array-Objekts als Methode aus dem Prototypen kommt. Kann natürlich nicht funktionieren, das war Unsinn von mir.

            (2) Das bringt mich aber auf eine andere Frage: Array.length und Kollegen, wie Object.length, Function.length, Date.length - das ist immer die Anzahl der Parameter, die die Konstruktorfunktion formal erwartet. Muss man das ausführlicher dokumentieren? Ich hätte das mit nein beantwortet.

            (3) Danke für die Einordnung des Artikelanspruchs. Das hilft mir beim Abrunden meiner laufenden Überarbeitung des Objekte-Artikels (auf meiner User-Seite als Temp-Seite verlinkt, falls Du Dir das anschauen willst).

            Gruß Rolf

    2. Lieber Rolf,

      1. Assoziative Arrays Den Abschnitt finde ich schwer verständlich. Ich will nicht einfach nach Gutdünken dran rumbasteln - daher hier meine Anregungen:
      • Es müsste klargestellt werden, dass das, was hier als assoziatives Array gezeigt wird, eben kein Array ist, sondern ein allgemeines Objekt.
      • Normale Objekte als Beispiel für assoziative Arrays zu bringen, halte ich für nicht so gut. Damit förderst Du unnötig die Kritik, die im Objekte-Artikel über AAs geäußert wird. AAs sind sinnvoll, wenn die Schlüssel erst zur Laufzeit bekannt werden, also z.B. wenn man ein Dictionary oder eine Lookup-Tabelle braucht.

      hmm. Jetzt, da ich mich ein bisschen in die Array-Seiten einlese, stelle ich mir die Frage, was ein "assoziatives Array" eigentlich sein soll. In PHP ist ein solches das, was man in anderen Sprachen als Dictionary oder Hashtable bezeichnet, nämlich eine Datenstruktur, die alphanumerische Schlüssel für Daten verwendet:

      <?php
      $employees = array(
          'mueller' => array(
              'family-name' => 'Müller',
              'first-name' => 'Max',
              'age' => 24,
              'residence' => 'München'
          ),
          'doll' => array(
              'family-name' => 'Doll',
              'first-name' => 'Dieter',
              'age' => 25,
              'residence' => 'Berlin'
          )
      );
      
      foreach ($employees as $key => $value) {
          echo "employee '$key': ";
          print_r($value);
      }
      

      Das Wesentliche in PHPs assoziativen Arrays sind die alphanumerischen Indices. Bei einem herkömmlichen Array (lies: Feldvariable) sind die Indices streng numerisch, so auch in JavaScript. Will man die Idee von Dictionary/Hashtable in JavaScript umsetzen, so muss man ein generisches Objekt verwenden (siehe die Array-Elemente selbst), dem man die jeweiligen Schlüssel als Eigenschaftsnamen gibt. Das obige Beispiel ließe sich in JavaScript so lösen:

      const employees = {
          "mueller": {
              "family-name": "Müller",
              "first-name": "Max",
              "age": 24,
              "residence": "München"
          },
          "doll": {
              "family-name": "Doll",
              "first-name": "Dieter",
              "age": 25,
              "residence": "Berlin"
          }
      };
      
      for (var key in employees) {
          console.log("employee '"+key+"':");
          console.dir(employees[key]);
      }
      

      Die prototypischen Eingenschaften werden mit for-in nicht erfasst (es kommt die Eigenschaft length nicht vor), sodass das Iterieren über das Objekt fast wie bei einem PHP-Array möglich ist, abzüglich der bei JavaScript-Arrays sehr komfortablen forEach-Methode natürlich.

      Wobei wir nicht verheimlichen sollten, dass wir hier über mehrdimensionale Arrays/Datenstrukturen reden. Die einfache Variante wäre nämlich diese:

      <?php
      
      $rgb = array(
          'red' => '#FF0000',
          'green' => '#00FF00',
          'blue' => '#0000FF'
      );
      
      foreach ($rgb as $key => $value) {
          echo "'$key' has rgb value '$value'".PHP_EOL;
      }
      

      Das JavaScript-Pendant dazu:

      const rgb = {
          "red": "#FF0000",
          "green": "#00FF00",
          "blue": "#0000FF"
      };
      
      for (var key in rgb) {
          console.log(key+" has rgb value '"+rgb[key]+"'");
      }
      

      Was sagt ihr beide dazu?

      Liebe Grüße,

      Felix Riesterer.

      1. Hallo Felix,

        ich sage dazu, dass ich den ganzen Bereich für einen der schmutzigeren Teile von JavaScript halte. Es ist historisch gewachsen und nicht mehr änderbar, aber für gut designed halte ich das nicht.

        Das "assoziative Array", das hier im Wiki auftaucht, muss dringend von den Arrays weg und zu den Objekten. In meiner Überarbeitung zum Objekte und Eigenschaften Artikel, den Du ja auch schon entdeckt und bearbeitet hast :), gehe ich ein wenig darauf ein. Dort zeige ich auch eine ähnliche Struktur wie Du oben.

        Ich habe Orloks Stand zum Array jetzt nicht im Kopf, aber er muss noch dringend vor der Array vs Object Konfusion warnen: Arrays sind Objekte mit einer winzigen Besonderheit: dem length Property, das automatisch aktualisiert wird wenn man Indizes im Bereich 0 bis 2^31-1 verwendet. Verwendet man andere Indizes, verhält sich das Array wie ein stinknormales Object.

        for...in iteriert übrigens sehr wohl über die Prototypen. Aber das length Property eines Array hat das Attribut enumerable:false, und die diversen Eigenschaften von Array.prototype und Object.prototype ebenfalls. Darum siehst Du sie nicht. Siehe dazu Object.keys und Object.getOwnPropertyNames, bzw. den in Arbeit befindlichen Artikel auf meiner Benutzerseite :)

        Rolf