Archiv

Archiv seit 2004

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit einem Tag mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Fehler bei Vorlage * Parametername unbekannt (Vorlage:Autoarchiv-Erledigt): "Klein; Mindestbeiträge" Fehler bei Vorlage (Vorlage:Autoarchiv-Erledigt): Der Wert des Parameters Zeigen wurde im Namensraum "Diskussion" mit "Nein" angegeben.

@PerfektesChaos: Ich würde Dich bitten einfach mal selbst in der Dokumentation nachzuschauen, bevor Du begründete und belegte Informationen zum zweiten Mal überschreibst. Das was typeof zurückliefert ist immer ein lowercase-String. Es ist daher weder eine vernüftige Referenz für die in den Sprachspezifikationen definierten Typen, noch kann man es einfach in einen < code >-Tag schreiben. Die Ausführung von number; erzeugt nämlich im Gegensatz zu Number; eine Fehlermeldung.

Da die Namen in den ECMA Language Specification genauso wie in allen wichtigen Dokumentationen (z.B. [1][2]) immer mit einem Großbuchstaben beginnen, sollten wir das auch. Ich werde die etablierte Schreibweise daher wieder im Artikel herstellen. // Martin K. (Diskussion) 14:37, 26. Sep. 2014 (CEST)Beantworten

Bring hier bitte keine Verwirrung hinein.

• Wenn du es als Namen der drei Basistypen verwendest, dann kannst du Boolean, Number und String mit Großbuchstaben schreiben; jedoch nicht als <code> – das ist es nämlich nirgendwo nirgends nicht.
• Wenn es das Resultat von typeof sein soll, wie es die einleitende erste Zeile des Abschnitts Datentypen suggeriert, dann muss es Kleinschreibung sein, und dann und nur dann ist es auch<code>.
• Verwechsele es bitte nicht mit den Klassenfunktionen zu den Primitiva.
• Ich träume in ECMA. --PerfektesChaos 14:46, 26. Sep. 2014 (CEST)Beantworten

Entschuldige, ich hatte tatsächlich überlesen, dass Du beim zweiten Mal umformuliert und nicht einfach nur revertiert hattest.

Bei Lichte betrachtet ist jedoch der gesamte Abschnitt JavaScript#Datentypen ein ziemlicher Murks, weil hier nicht die Daten-Typen, sonden die Funktion von typeof in epischer Breite beschrieben wird. Da typeof jedoch nur Mittel zum Zweck ist und zudem einige Eigenheiten an den Tag legt, die einem grundlegenden Sprachverständis eher im Wege stehen. Ich würde daher vorschlagen, den kompletten Abschnitt so umzubauen, dass typeof bestenfalls in einem abschließenden Satz erwähnt wird. // Martin K. (Diskussion) 15:06, 26. Sep. 2014 (CEST)Beantworten

• Entschuldigung akzeptiert.
• Bitte beachte bei deinem weiteren Wirken, dass es bei den primitiven Typen drei Fälle gibt:
  1. Die Erwähnung des primitiven Typs, wie in der ECMA im Standard und laufenden Texts geschieht; korrekte Notation:

     Boolean

  2. Das Resultat von typeof – korrekte Notation:

     boolean

  3. Die Klassenfunktion, die das zugeordnete Objekt generiert:

     Boolean oder deutlicher Boolean()

• Es gibt sogar die Typen Null und Undefined, die jeweils nur einen einzigen Wert enthalten. Aber null ist leider kein Resultat von typeof.
• Dagegen liefern Funktionen zwar einen eigenen typeof, nämlich function, sind aber kein Typ im eigentlichen Sinn.
• Alles ziemlich verwirrend. Wenn du dort überarbeitest, würde ich eine tabellarische Darstellung aller Typen und typähnlicher Gebilde empfehlen.

LG --PerfektesChaos 15:32, 26. Sep. 2014 (CEST)Beantworten

Da in JS alles ein Objekt ist (also auch die Funktionen) ist Function eigentlich doch auch ein ganz normaler Datentyp?! // Martin K. (Diskussion) 15:50, 26. Sep. 2014 (CEST)Beantworten

Ich muss nochmal auf dieses Thema zurückkommen, da die Schreibweise an vielen Stellen im Artikel schlicht falsch ist:

• Wie oben schon verlinkt beginnen in allen relevanten Referenzen die Typnamen mit einem Großbuchstaben.
• Und auch Number oder String wäre in soweit korrekt, als dass es sich dabei um ausführbaren Code handelt (Nämlichen den aufruf der gleichnamigen Konstruktorfunktionen).

Sowas wie number oder string hingegen macht einfach keinen Sinn:

• Die Ausführung dieses „Codes“ führt lediglich zu einer Fehlermeldung: ReferenceError: string is not defined
• Da das, was type of zurückliefert ein String ist und kein Bezeichner, müsste da wenn überhaupt "number" oder "string" stehen. Was natürlich im Fließtext noch weniger Sinn macht.

Ich würde daher nochmal vorschlagen die Typbezeichnungen im Fließtextgrundsätzlich gemischt zu schreiben und die lowercas-Schreibweise nur dort zu benutzen, wo sie im Rahmen von type of angebracht ist. Und auch generell, sollten wir darauf achten, dass das was in < code > steht syntaktisch korrekter ausführbarer Code ist. Ich werd das jetzt malentsprechen anpassen. // Martin K. (Diskussion) 09:59, 26. Okt. 2014 (CET)Beantworten

Ich empfahl weiter oben schon eine tabellarische Übersicht aller Typen, mitsamt null und undefined und den Konstruktorfunktionen (wo vorhanden) und der Doppelrolle der function und vor allem der Resultate von typeof. Anders wirst du Fälle wie den Wert null vom Typ Null mit dem typeof von object oder die Funktion vom Typ Object mit dem typeof von function niemandem verständlich rüberbringen. VG --PerfektesChaos 10:39, 26. Okt. 2014 (CET)Beantworten

Mir ging es imkonkreten Fall auch eher um die generelle Schreibweise von Typ-Namen im ganzen Artikel – nicht nur um den Abschnitt Typisierung. // Martin K. (Diskussion) 10:57, 26. Okt. 2014 (CET)Beantworten

Solange im zentral zuständigen Abschnitt nicht sauber durchdekliniert wurde zwischen Name, Konstruktorfunktion und typeof-Ergebnis, wird auch in den anderen Abschnitten niemand begreifen, was wann gemeint ist, und es immer wieder jemand auf etwas anderes umbauen. VG --PerfektesChaos 12:07, 26. Okt. 2014 (CET)Beantworten

Das „inoffizielle Logo“ wird derzeit zentral von Wikidata als Logo-Eigenschaft für JavaScript definiert.

Wird sonst (zumindest in der deutschen Wikipedia) jeder unbequellte Scheiß entfernt, ist hier scheinbar ein „inoffiziell“ ausreichend. Was es natürlich nicht ist.

Wieso also wird das schwarzgelbe Logo in diesem Artikel verwendet? Ist »Chris Williams« jemand besonderes? Das Logo wird jedenfalls auch für http://jsconf.com/ verwendet. Ist es nun ein inoffizielles JavaScript-Logo, oder ist es eine Logovorlage für »JSConf™«?

Hier ein paar andere inoffizielle Logos:

• 
• Datei:Logo JS 2005.jpg
• 
• 
• 
• 
• 

Davon ernstgemeint ist höchstens das rechte Bild, denn bspw. in der englischen Wikipedia wird bei Programmiersprachen ohne Logo (wie ECMAScript/JavaScript) ein Quellcodeausschnitt nebst Dateiendung in der Infobox verwendet; das gibt es auch in der deutschen, etwa bei HTML. Das finde ich einen guten illustrativen Kompromiss gegenüber keinem Logo – ein selbstgemaltes und unbelegtes und inoffizielles Logo sollte jedenfalls außer Frage stehen. -- Gohnarch^░ 13:31, 24. Dez. 2014 (CET)Beantworten

Volle Zustimmung. --Trustable (Diskussion) 14:22, 24. Dez. 2014 (CET)Beantworten

Ok, also kein Logo. Das „rechte Bild“ halte ich jedoch auch für ungeeignet (es ist einfach ein Mimetype-Icon eines Icon-Sets … von einem Wikipedianer). Wenn es denn genehm ist würde ich eine solche bildliche Darstellung eines JavaScripts erstellen (analog zum genannten HTML und anderen Auszeichnungssprache)? Evtl. nützlich dafür wären inhaltliche Vorschläge. ↔ User: Perhelion 16:10, 28. Feb. 2016 (CET)Beantworten

Ich finde ein Beispiel ungeeignet, in dem Tiere getötet werden, nur um ein Element der Sprache zu verdeutlichen. Ich unterrichte JavaScript im Gymnasium und wurde durch eine Schülerin auf diesen Umstand aufmerksam gemacht. Es wird sich doch mitnichten ein neutraleres Beispiel finden lassen, wo Otto nicht sterben muß? Vielen Dank.

var neue_katze = function () {
    var lebensZahl = 7;
    var maunz = function () {
        return (lebensZahl > 0) ? "miau" : "örks";
    };

    // gibt neues objekt zurück
    return {
        toeten: function () {
            lebensZahl -= 1;
            alert(maunz());
        }
    };
};
var otto = neue_katze();
otto.toeten(); // miau

(nicht signierter Beitrag von 217.186.143.203 (Diskussion) 13:03, 30. Aug. 2015 (CEST))Beantworten

Sei Mutig und schlag ein anderes Beispiel vor. -- HerrLock 15:06, 30. Aug. 2015 (CEST)Beantworten

Einige der Codebeispiele nutzen die automatische Ergänzung fehlender Semikolons durch den JavaScript-Parser, wobei das aber nicht einheitlich gehandhabt wird. Da das Weglassen von Semikolons von der statischen Codeanalyse in der Regel bemängelt wird, schlage ich vor, einheitlich die Semikolons explizit anzugeben. Meinungen dazu? --Stefan Weil (Diskussion) 19:48, 28. Mai 2016 (CEST)Beantworten

Ja, sehr gern, sollten natürlich vorbildlich sein.

Ich hab jetzt nicht reingeguckt, aber alle Klammern und Semikolonse und so sollten am Platz sein.

Wir präsentieren hier doch nicht das 1990er-Jahre-Gemurkse irgendwelcher „Webdesigner“ kurz vorm Abi.

Insbesondere sollte http://jshint.com/ in der härtesten Einstellung jeden Block absegnen.

LG --PerfektesChaos 21:11, 28. Mai 2016 (CEST)Beantworten

JSHint ist jetzt zufrieden. --Stefan Weil (Diskussion) 22:14, 28. Mai 2016 (CEST)Beantworten

Wurde in ECMAScript 6 nicht der Sprachkern um Klassendefinitionen erweitert? -> Ist JavaScript seit ES6 "klassenlos?"

Haut rein (nicht signierter Beitrag von 2A02:8071:238A:4100:12C:8CE5:68A7:655 (Diskussion) 02:13, 1. Jun. 2016 (CEST))Beantworten