JavaScript-Referenz - Loose Typing / dynamische Typkonvertierung

[Matthias Scharwies]

Hallo zusammen,

ich brüte grad über "Loose Typing" - der dynamischen Typkonvertierung in JavaScript. Gehört das zu /Datentyp oder /Variable oder in beide Artikel?

Bis jetzt ist der Artikel zu Datentypen ja ein Stub:

Finde den Fehler! 😀

nicht nur diese 4, sondern auch BigInt wird hier nicht erklärt. 😟

Das ist in meinem Entwurf (fast) alles drin, doch bevor ich ihn vorstelle, würde ich gerne wissen, ob

• nur eine Erwähnung oben rein muss, dass die Typkonvertieurng in JS/Variablen näher beschrieben wird
• oder ich einen ganzen eigenen Abschnitt brauche.

BTW: Molily hat in seiner Referenz da nix drüber, aber etwas im Artikel zu Objektabfragen.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

Bis jetzt ist der Artikel zu Datentypen ja ein Stub

Äh, nein? Aus meiner Sicht ist das eine Verteilerseite. Es ist vielleicht nicht gut, dass undefined und null nur auf der Verteilerseite behandelt werden und für die übrigen Artikel lediglich verwiesen wird.

Ich wollte aber eine Doppelung von Beschreibungen vermeiden.

BigInt ist im Testwiki ein Redlink, im Hauptwiki gibt's den Artikel aber.

D.h. auf dieser Verteilerseite kann man anreißen, wozu man diese Typen braucht und sollte den Rest den Detailseiten überlassen. Beispiele würde ich hier nicht machen.

Man sollte sich auch klar werden, welche Art von Artikel "Datentypen" ist. Ist das ein Artikel für Leute, die noch nie JS gesehen haben? Oder sollten die nicht eher zu "Einstieg in JavaScript" geschickt werden? Wo dann auch ein paar weniger konkrete Worte zu Datentypen fallen sollten und der Hinweis, dass eine genauere Übersicht unter [[Datentypen]] zu finden sei. D.h. die "Einstieg in JavaScript" Card sollte VOR der "Allgemeines" Rubrik stehen, ganz alleine, mit dem Hinweis: "Wenn Sie noch nie etwas von JavaScript und Programmieren gehört haben, sollten Sie hier einsteigen".

Bei denjenigen, die unter "Allgemeines zu JavaScript" schmökern, kann man dann voraussetzen, dass sie nicht komplett unbeleckt sind und auf den Seiten zu den einzelnen Typen auch Beispiele machen. Die Leser*innen wissen dann auch schon, dass es Operatoren gibt und dass !a die Negation eines Logikwertes liefert. Auf die Pilatus-Frage ("Was ist Wahrheit") geht dann der Boolean-Artikel genauer ein.

if (demoElement.hidden) {
   demoElement.textContent = "Element anzeigen";
}
else {
   demoElement.textContent = "Element verbergen";
}

demoElement.hidden = !demoElement.hidden;

Die Variante

demoElement.textContent = "Element " 
                        + (demoElement.hidden ? "anzeigen" : "verbergen");
demoElement.hidden = !demoElement.hidden;

würde ich in diesem Teil der Artikel allerdings zurückhalten (höchstens erwähnen, dass es mit dem [[ternären Operator]] eine kompaktere Methode gibt). Hier wäre auch Terminologie zu pflegen, ist das der ternäre Operator oder der bedingte Operator oder ein bedingter Ausdruck oder der (ternäre) Auswahloperator (Wikipedia) oder der Entweder-Oder Operator (auf der Seite Operatorenrangfolge)? Aus meiner Sicht ist "ternärer Auswahloperator" gut, da steckt die Arität (Stelligkeit) des Operators drin und seine Aufgabe.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias Scharwies,

Bis jetzt ist der Artikel zu Datentypen ja ein Stub

Äh, nein? Aus meiner Sicht ist das eine Verteilerseite. Es ist vielleicht nicht gut, dass undefined und null nur auf der Verteilerseite behandelt werden und für die übrigen Artikel lediglich verwiesen wird.

Man sollte sich auch klar werden, welche Art von Artikel "Datentypen" ist.

So wie ich das seit 2018 verstanden habe, soll JavaScript/Sprachelemente die Sprachelemente vorstellen - in einer Art Referenz/Reihe von Grundlagenartikeln, in der alles vorgestellt wird und auf die man immer wieder zurückkommt/en kann.

In einem Tutorial wird ein Anwendungsbeispiel Schritt für Schritt aufgebaut und dann eben einmal eine Schleife verwendet. Im Artikel JavaScript/Schleife werden alle Schleifen der Reihe nach vorgeführt und ihre Eigenarten besprochen. In JavaScript/Verzweigung genauso, wobei da sogar noch der ternäre Auswahloperator drin ist. Gut!

In JavaScript/Variable gibt es „gewachsene“ Strukturen: Erst kommt var, danach dann let und const - wobei es für beide auch jeweils eigene Seiten gibt. Du hattest im Jan 2021 in deinem Benutzernamensraum einen Neuaufbau angefangen, nach dem ich mich jetzt gerichtet habe. Da müssen wir duplicate content bereinigen und zurückschneiden.

JavaScript/Datentyp mag eine „Verteilerseite“ sein - so wie JavaScript/Operatoren. D.h., dass man von der Startseite mehrfach auf Verteilerseiten geleitet wird, bis man zum gewünschten Ziel kommt.

Ist das ein Artikel für Leute, die noch nie JS gesehen haben? Oder sollten die nicht eher zu "Einstieg in JavaScript" geschickt werden?

Ja, aber das ist ein Tutorial, keine Referenz.

Wo dann auch ein paar weniger konkrete Worte zu Datentypen fallen sollten und der Hinweis, dass eine genauere Übersicht unter [[Datentypen]] zu finden sei. D.h. die "Einstieg in JavaScript" Card sollte VOR der "Allgemeines" Rubrik stehen, ganz alleine, mit dem Hinweis: "Wenn Sie noch nie etwas von JavaScript und Programmieren gehört haben, sollten Sie hier einsteigen".

Ja, aber dann würde sich unser Wiki vorrangig an Anfänger richten - eigentlich ist für die ja die Seite "Wie fange ich an?" gedacht!

Das sind eben noch die unbeantwortete Fragen aus dem Nachbarthread:

• Wie soll das Kapitel JavaScript/Anweisung heißen?
• Was soll da inhaltlich rein?
  • Auf jeden Fall eben einen Hinweis auf use strict; damit man eben aktuellen Code als Basis hat. Die Altfälle kann man ja mit „Viele ältere Beispiele haben noch ...“ erwähnen.^[1]
  • Und dann eben noch kurz, wie man JS in Webseiten einbaut, und noch kürzer, dass es eben auch auf den Server laufen kann.

Bei denjenigen, die unter "Allgemeines zu JavaScript" schmökern, kann man dann voraussetzen, dass sie nicht komplett unbeleckt sind und auf den Seiten zu den einzelnen Typen auch Beispiele machen.

Ja, wobei das eben auch mal diskutiert werden sollte, ob man das auf der Portalseite "Allgemeines zu JavaScript" und dann woanders "Sprachelemente" nennt. Wir müssen uns die Zeit nehmen, gemeinsam Seiten anzuschauen und dann zu überlegen,

• was man machen muss^[2]
• wie man das macht
• wer das übernimmt.

---

Ich lade alle zu einem Stammtisch / Workshop ein, an dem man das alles besprechen kann.

Herzliche Grüße

Matthias Scharwies

---

1. Ich sag's immer wieder: Das war der Fehler, dass ich 2014 Stefan Münz' Inhalte aus der Doku übertragen hatte. Damals hätte es wsl. auch nichts gebracht, Code vorzustellen, der im IE8-10 (oder gar IE6!) noch gar nicht funktioniert hätte. ↩︎

2. Wir haben auf vielen Seiten Links zu Kangax, die damals den Browser-Support angezeigt hatten, die Seite ist tot! (Mit einer Vorlage könnten wir das jetzt zentral abschalten - so müssen wir alle Seiten einzeln durchgehen.) ↩︎

[Rolf B]

Hallo Matthias,

bin gerade am Handy, darum kurz.

Nein, ich bin nicht angefressen. Aber darf ich nicht eine Meinung verteidigen?

Doch, Kangax funktioniert prima und ist aktuell.
Vielleicht eine andere URL?

Ich verstehe, dass du das Thema treiben willst. Ich möchte aber das Makeover voranbringen, deshalb kann ich nicht viel Zeit investieren.

Rolf

[Matthias Scharwies]

Servus!

Wir haben auf vielen Seiten Links zu Kangax, die damals den Browser-Support angezeigt hatten, die Seite ist tot!

Doch, Kangax funktioniert prima und ist aktuell.
Vielleicht eine andere URL?

ja, sorry, dann formuliere ich mal um: Wir haben im Wiki viele Links von 2016, die 404 liefern. Da wir da keine Vorlage haben, muss man manuell durchgehen. Ob man bei Methoden, wo man 2016 den Browser-Support ermitteln musste, das heute noch tun will, ist die andere Frage.

Ich verstehe, dass du das Thema treiben willst. Ich möchte aber das Makeover voranbringen, deshalb kann ich nicht viel Zeit investieren.

Kein Problem!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

okay. Hast Du einen Überblick über die verwendeten Links? Oder soll ich die per SQL raussuchen?

De facto bräuchte man wohl eine Art "Kompatibiltät"-Vorlage, die Links zu caniuse und/oder Kangax erzeugen kann und das dann ordentlich darstellt. {{Caniuse|foo}} kann dann in der Caniuse-Vorlage einfach auf {{Kompatibilität|caniuse=foo}} abgebildet werden.

Müsste man ebenfalls erstmal diskutieren und nicht sofort losbasteln 😉

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

okay. Hast Du einen Überblick über die verwendeten Links? Oder soll ich die per SQL raussuchen?

Nur über die erweiterte Suche.

De facto bräuchte man wohl eine Art "Kompatibiltät"-Vorlage, die Links zu caniuse und/oder Kangax erzeugen kann und das dann ordentlich darstellt. {{Caniuse|foo}} kann dann in der Caniuse-Vorlage einfach auf {{Kompatibilität|caniuse=foo}} abgebildet werden.

Ich glaube nicht.

Hier bei Node.contains wurde das am 10.06.2018 eingefügt.

Mittlerweile finde ich es hier gar nicht mehr: https://compat-table.github.io/compat-table/es6/

Bei caniuse gibt es über 97%: https://caniuse.com/mdn-api_node_contains

Imho gab es viele dieser JS-Sachen damals nicht auf caniuse.

Müsste man ebenfalls erstmal diskutieren und nicht sofort losbasteln 😉

Ja, reden wir am 29.01. (Morgen ist Elternabend - mein Sohn hat mich schon angekündigt als
„Mein Vater ist Türsteher im Flaschenkind und kennt den Marquardt persönlich!“)

Herzliche Grüße
Matthias Scharwies