Tach!

Ich würde es gern sehen, wenn die Instantiierungen anonymer Funktionen durch die Variante 2, also die IIFE-Schreibweise ausgetauscht würden.

sagte nicht Crockford, er möge es nicht, wenn die Argumente-Klammer außerhalb der umspannenden Klammern läge? So á la "da hängen die Eier 'raus"?

Der kann ja sagen, was er will, am Ende hat er zwar viel Erfahrung, aber er ist genausowenig Gott oder Gesetzgeber wie ich. (Will sagen, er hat das Recht auf die Wahrheit nicht gepachtet und ich will mir das auch auf keinen Fall anmaßen.) Sein Argument zeigt auch nur eine Vorliebe und ist kein technisch begründeter Einwand. (Es sei denn, du hast den Teil weggelassen. Ich kannte bis eben nicht, dass er sich dazu in der Form geäußert hat, geschweige denn, wie er es konkret getan hat. Insofern will ich da jetzt nicht zu viel Gewicht drauflegen.) Bei einer Funktion an sich ist jedenfalls auch keine zusammenhaltende Klammer drumherum, da hängt quasi alles raus, also das Schlüsselwort function und dazu die Parameterliste und der Funktionskörper. (Und hey, es gibt Kontexte, da sind heraushängende Eier kein Makel. An Ostersträuchen beispielsweise.)

Aber das ist meines Erachtens ziemlich egal. Gerade für Anfänger ist es das. Inwiefern ich damit Anfängern den Einstieg in die Instanziierung von Objekten mit dem Schlüsselwort new verbaue... da bin ich als Pädagoge eher gelassen, denn meine Erfahrung zeigt, dass man bereits Bekanntes durchaus in neue Kontexte einzuordnen lernt.

Ich sag mal, das new hat seinen Platz an einer ganz anderen Stelle. Es ist besser da aufgehoben, wo es darum geht, mehrere Instanzen von einem Funktionsobjekt (anderswo Klasse genannt) zu erzeugen. Hier geht es nur um das Erzeugen eines Scopes, und dass man das nur hinbekommt, indem man eine Funktion so komisch notiert und aufruft, ist schon eigenartig genug. Doch das ist die gängige Praxis, und insofern sag ich mal, ganz weg mit der new-Version, sagen dass das eine IIFE ist, man sie für den Scope braucht, Verweis auf das Glossar hinzufügen und gut ist.

Warum soll man z.B. nicht verschiedene Spielstände zum Weiterspielen anbieten können? Das geht nur mit einer Klasse anstelle einer ID!

Ok, das ist ein nicht ganz dummes Anwendungsbeispiel. Wenn du das in einem Nebensatz als Beispiel erwähnst, wird das auch klarer, warum du da eine Klasse verwendet hast, und zeigt auch, dass eine ID für andere Anwendungsfälle ebenfalls möglich wäre.

Das mit Iterationsmethoden und Callback-Funktionen empfinde ich als ein kleines bisschen fortgeschrittener, als es ein reines Anfänger-Tutorial im Kern verkraftet.

Einverstanden. Aber zumindest die for-of-Version ist verständlich und auch schöner als for mit i. Die könnte man erwähnen und hätte somit auch noch drin, dass man leider auf manche Dinge noch verzichten muss, um Kompatibilität mit alten Browsers zu bewahren - ein nicht ganz unwichtiges Thema, wenn es um Javascript geht.

Bei der "Was fehlt noch?"-Rubrik könnte man solche Gedanken anbringen. Oder man schreibt gleich ein ganz anders konstruiertes Beispiel und macht ein Anfänger-II-Tutorial daraus. Magst Du (<I>) ...?

In der Tat, den funktionale Ansatz nur in einem solchen "Ausblick"-Absatz zu erwähnen, damit kann ich mich anfreunden. Zum Rest ... prokrastinieren wir das mal etwas.

In check() ist es besser, statt !finished nur auf finished zu prüfen und in dem Fall die Funktion zu verlassen. Das reduziert eine Einrückungsebene, besonders weil es keinen Else-Zweig oder generellen Code nach diesem if kommt.

Hmm. Ja. Im Prinzip schon. Aber dann müsste ich return einführen. Das habe ich zwar implizit schon getan, indem ich Rückgabewerte von Methoden in Variablen ablege, wie ich aber mitten aus einer Funktion aussteige, egal ob mit oder ohne Rückgabewert, wollte ich nicht ohne konkreten Anlass einführen.

Etwas abzubrechen, weil die Bedingungen eine Fortführung nicht erlauben, ist kein unübliches Vorgehen. Das muss auch nicht ausgewalzt werden. Es reicht zu sagen, dass bei erfüllter Bedingung die Funktion mit dem return verlassen werden kann. Das verstehen Anfänger vermutlich auch, denke ich.

"Es hat einen Sinn, die Variablendeklaration an den Anfang der Funktion zu setzen und nicht erst im Anweisungsblock des if-Statements. Das ist gute Programmierertradition, da damit der Code für andere übersichtlicher wird." - Njein, kann man so sehen, kann man aber auch anders sehen.

Stimmt, kann man. Aber wenn man die Sache mit dem Scope üben will, dann ist es einleuchtend, wenn man die Deklaration an oberster Stelle des Scopes vornimmt. Findest Du nicht?

Im Prinzip ja. Das zeigt zwar deutlicher, dass die Variablen im gesamten Scope verfügbar sind, reißt mir aber (in einigen, nicht in allen Fällen) Deklaration und Anwendungsgebiet unnötig auseinander.

Besser sind kleinere lokale übersichtliche Scopes, statt dass man im Großen versucht den globalen Scope zu meiden, im kleinen aber Variablen im gesamten Scope rumliegen hat. Im Falle von i ist es sogar unübersichtlicher, weil i nur ganz lokal benötigt wird und nicht in der gesamten Funktion.

Bedeutet das, dass Du gerne noch mehr Funktionen verschachteln möchtest? Hier in diesem konkreten Anfänger-Tutorial? Oder war das eher eine allgemeine Marschrichtung für erfahrenere JavaScriptler?

Man muss Gründe nicht an den Haaren herbeiziehen, man muss sich auch nicht totstrukturieren, und man muss nicht den Aufmerksamkeitsbogen in einem Anfängertutorial überspannen, indem man zu viele zwar wichtige, aber nicht überlebenswichtige Details einbaut. Insofern, nein, ich möchte nicht schachteln, um des Schachtelns willen. Das kann gern so bleiben, wie es jetzt ist. Das wäre eher ein Thema für die Fortgeschrittenen. Da passt dann zur Erklärung des funktionalen Ansatzes, dass sich damit auch hervorragend kleine Scopes bilden, für Dinge, die nur dort lokal benötigt werden.

Zur Ermittlung ob full oder nicht, kann man nach dem ersten false die Schleife abbrechen, "fuller" wird es nämlich mit den anderen Werten auch nicht.

Tja, dann müsste ich break einführen. Wollte aber sparsam darin sein, was ich alles auf einen echten Anfänger los lasse.

Totsparen sollte man sich auch nicht. Das einzelne break bläht den Code nicht unnötig auf, und sinnvoll ist es außerdem.

Warum nur um Himmels Willen hat man das so gemacht?? Diese ganzen NodeLists haben diese bequemen Iterationsmethoden nicht. Was haben die sich dabei nur gedacht?

Das MDN beantwortet die Frage auch nicht wirklich, obwohl es sie doch konkret formuliert. Why is NodeList not an Array? Da wird auch nur erwähnt, dass NodeList Array nicht in der Prototype-Chain von Nodelist ist.

"Wenn wir prüfen wollen, ob der String leer ist, genügt es nicht mit dem ==-Operator zu prüfen, da JavaScript intern Wertetypen umrechnen kann, um verschiedene Typen miteinander zu vergleichen." - Oh doch, das genügt in dem Fall vollkommen, weil beim Vergleich von zwei Strings (hier className mit einem Stringliteral) kein anderer Wertetyp beteiligt ist.

Es könnte eine Klasse "0" oder "000000" benutzt werden - extrem unwahrscheinlich,

Auch dann gibt es in JavaScript kein Problem. In PHP ergibt "0" == "000" zwar true, weil PHP auch in String Zahlen zu erkennen versucht, JavaScript lässt sowas aber kalt, solange nicht etwas vom Typ Number eine Konvertierung erforderlich macht.

aber irgendwie hielt ich es für nötig, die Typsicherheit bei Vergleichen von beiden Seiten aus vorzuführen. Es sollte einmal ein typsicherer Vergleich nötig sein und einmal ein lose typisierter. Hättest Du bessere Beispiele gewusst, um das Problem zu veranschaulichen?

Hab ich im Moment nicht.

className ist definiert als string, und selbst wenn man da 0 (Integer-Literal) reinschreibt, kommt "0" (String) beim Lesen raus.

Genau, und "0" ist falsy, ebenso wie "00000".

Nein, "0" ist true. Das zeigt sich ganz eindeutig an der Konsole bei doppelter Negation. !!"0" und !!"000" ergibt true, !!0 ergibt false.

Die Verwendung eines //<![CDATA[...//]]>-Blocks ist laut Standard nicht notwendig.

Das ist alles schön und gut, wenn kein String in der Form "</script>" enthalten ist.

Ein </ von anderen Elementen als script reicht in der Theorie auch schon, und das dürfte ein häufigerer Anwendungsfall sein als script im script-Block.

Bastele ich einen CDATA-Block darum, habe ich kein Problem. Ohne diesen Block könnte mir das um die Ohren fliegen (und ist es in der Vergangenheit auch).

Ja, aber, ... da fliegen auch noch ganz andere Dinge los, wenn man das mit dem Kontextwechsel generell noch nicht so intus hat.

Wenn man es "richtig" macht, stochert man lieber nicht in der Ausgabe herum, um Werte für die Geschäftslogik zu bekommen. [...] Besser ist, man hat eine separate Datenhaltung.

Darüber hatte ich mir im Vorfeld einige Gedanken gemacht. Ich hatte ein Array mit den 3x3 Feldern, wobei jedes Array-Element, welches für ein Feld stand, ein Objekt war, welches unter anderem das betroffene Elementobjekt enthielt. Etwas in dieser Richtung:

var board = [
    [
        {
            element: <HTMLTableCellElement>,
            value: "x"
        },
        {
            element: <HTMLTableCellElement>,
            value: ""
        },
        {
            element: <HTMLTableCellElement>,
            value: "o"
        }
    ], // weitere Arrays für Zeilen 2 & 3
];

Das krankt immer noch daran, dass es Geschäftslogikdinge mit Ausgabedingen mixt.

Ich habe dann festgestellt, dass das Prüfen und Ermitteln von Gewinner oder Unentschieden für einen Anfänger unnötig kompliziert wird. Deshalb habe ich mich für eine Anfänger-Lösung mit der className-Eigenschaft entschieden.

Versuch das mal - zumindest in Gedanken - mit einem reinen Datenarray als Grundlage umzusetzen. Wie würden dann die Berechnungen aussehen und wie sieht dann die Ausgabe aus? So kompliziert stell ich mir das nicht vor. Und man hätte eine saubere Trennung der Verantwortlichkeiten. Pädagogisch gesehen könnte man natürlich auch erstmal das "Kuddelmuddel" zeigen, um daraus zu lernen, dass es einen besseren Weg gibt, der einerseits zeigt, dass bei Erweiterungen nicht das gesamte Konstrukt gefährdet oder in Mitleidenschaft gezogen wird, andererseits durch die Trennung man etwas mehr Arbeit mit der Übersicht hat, was sich aber letzten Endes eher als Vorteil herausstellt, mehrere kleine Einheiten als eine große zu haben. - Das wäre dann aber auch ein Thema für einen Fortsetzungsartikel.

dedlfix.