Diskussion:JavaScript

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „JavaScript“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

Archiv seit 2004

Wie wird ein Archiv angelegt?

Automatische Archivierung

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.

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Variablen und Werte

Einwand: siehe zusammenfassungszeile http://de.wikipedia.org/w/index.php?title=JavaScript&diff=104541928&oldid=104541005 (nicht signierter Beitrag von 77.179.79.174 (Diskussion) 22:29, 18. Jun. 2012 (CEST))

gudn tach!

"For example, a variable is not required to have its type declared [...]" (ECMAScript Language Specification)

"The typeof operator returns a string indicating the type of the unevaluated operand. operand is the string, variable, keyword, or object for which the type is to be returned." (Client-Side JavaScript Reference, mozilla.org)

erklaerungen wie "Der Datentyp des Werts, den die Auswertung eines Ausdrucks e ergibt, lässt sich mit typeof e ermitteln." sind wesentlich umstaendlicher und auch unverstaendlicher (siehe WP:OMA) als "Der Datentyp einer Variablen v lässt sich mit typeof v ermitteln.".

ich werde deswegen jetzt den urspruenglichen stand wiederherstellen und bitte dich, von einem erneuten revert erst mal abzuesehen und stattdessen den verlauf der diskussion hier abzuwarten. -- seth 21:55, 19. Jun. 2012 (CEST)

Das zitat aus der spezifikation 262 stammt aus der informellen einleitung und handelt eher nicht von javascript-variablen. Im ganzen rest der spez. existiert das konzept "typ von variable" nicht.

Das zitat von mozilla.org ist falsch. "unevaluated" stimmt nicht mit dem ueberein, was im standard steht (11.4.3 The typeof Operator), typeof (5+5) ist legal, und der operand ist weder "string", "variable", "keyword", noch "object".

Korrektheit ist wichtiger als verstaendlichkeitsvorgaukelung durch treffen falscher aussagen.

Variablen aendern ihren typ nicht, und werte aendern ihren typ auch nicht. Erst wenn man diese begriffe ohne not sinnlos vermischt und zeitlich versetzt mit dem wort "variable" manchmal wert und manchmal variable meint, kann man zu der behauptung kommen, variablen würden ihren typ aendern. Diese letzte behauptung ist das schlimme missverstaendnis, welches man mit geeigneter wortwahl vermeiden kann. --77.179.89.196 22:38, 19. Jun. 2012 (CEST)

Noch ein gedanke, bzgl. oma-verstaendlichkeit. Sollte man das konzept "typ von variable" erfinden und definieren als "halt immer der typ des in der variablen enthaltenen wertes", dann ist "typ einer variable kann sich aendern" eine zwecklose verkomplizierung der aussage "beim schreiben in eine variable wird der vorher enthaltene wert ignoriert". --77.179.89.196 23:28, 19. Jun. 2012 (CEST)

gudn tach!

das zitat ist nicht falsch, sondern deiner meinung nach der inhalt. ;-p ich hatte den text uebrigens von https://developer.mozilla.org/en/JavaScript/Reference/Operators/typeof kopiert.

das mit der korrektheit (vs. pseudo-verstaendlichen, aber falschen aussagen) ist sicher richtig. aber die frage ist halt, was im kontext eine falsche aussage ist bzw. ob es falsch ist, vom datentyp einer variable zu sprechen. in diesem sinne moechte ich deiner these der verkomplizierten aussage widersprechen. beim +=-operator z.b. wird (im allgemeinen) der vorher enthaltene wert nicht ignoriert. dass variablen mit datentypen verknuepft sind und diese aendern koennen wird deutlicher anhand von funktionen wie settype (in php). denkbar ist sowas auch in javascript[1]. du wuerdest nun vermutlich entgegnen, dass nicht die variable ihren typ aendere, sondern nur der in der variablen enthaltene wert seinen typ aendere bzw. ein neuer wert eines anderen typs in der variablen gespeichert werde. im sprachgebrauch wird das aber eben einfach verkuerzt, und zwar ohne, dass dadurch falsche informationen transportiert werden. denn eine variable ist fest mit einem typ verknuepft, ob man nun den umweg ueber den wert der variablen geht oder sogar ueber die interne repraesentation im speicher ist in diesem kontext wurscht.

aber ich glaube auch, dass wir diese allgemeine frage hier gar nicht unbedingt zu klaeren brauchen. vielleicht finden wir fuer die beiden verbleibenden stellen, um die es noch geht,[2] bessere formulierungen.

zur ersten stelle (typeof): der gag an deinem vorschlag ist, dass das 'e' eine metasyntaktische variable und kein eigentlicher javascript-ausdruck ist (sondern einen solchen nur symbolisiert). das macht die sache imho etwas komplizierter als wenn man etwas enger im javascript-sprachsystem bleibt und einfach von "typeof(v) mit v einer js-variablen" spricht. da aber im weiteren verlauf des abschnittes auch nur von werten gesprochen wird, sehe ich ein, dass es sinnvoll ist, typeof auch eher damit in verbindung in der einleitung zu nennen. nach einigem gruebeln denke ich deshalb nun auch, dass deine formulierung da vielleicht die bessere war (und mir faellt keine noch bessere ein). bevor ich aber meinen revert revertiere, koennen wir vielleicht noch klaeren, was man mit der zweiten stelle macht:

bei der zweitenstelle (dyn. typ.): da halte ich die derzeitige formulierung fuer adaequat, allerdings ist fraglich, ob es den nachsatz "was manchmal zu fehlern bzw. unerwuenschten effekten fuehrt" braucht. imho ist der ueberfluessig, weil alle spracheigenheiten irgendwann irgendwie zu fehlern oder unerwuenschten effekten fuehren koennen, wenn man falsch damit umgeht. ich schlage deshalb vor, den zweiten nachsatz zu loeschen. die kurze erklaerung, was dyn. typ. grob ist, halte ich jedoch wie gesagt fuer sinnvoll. details kann ja jeder im verlinkten artikel nachlesen, der dann uebrigens auch von typen von variablen spricht. -- seth 11:43, 20. Jun. 2012 (CEST)

+= ist nicht blosses schreiben, sondern lesen gefolgt von schreiben. phps settype liest ebenfalls einfach einen wert und schreibt einen anderen, wie man z.b. an dem verwirrten kommentar von Chris Sullins 18-Apr-2010 11:59 sieht. Das javascript-settype ist abfall mit hoechst eingeschraenkter funktionalitaet (vr als string uebergeben und das muss eine globale variable sein???), das aber auch nur einen wert liest und dann einen wert schreibt.

(Ja, ich entgegne also genau das, was du erwartet hast). Das ist eben genau das, was es ist. Mit einer variablen ist kein typ verknuepft - jedenfalls nicht in anderer weise als in der, dass werte typen haben, und man variablenwerte auslesen kann. Gerade weil es in anderen sprachen durchaus moeglich und sinnvoll ist, tatsächlich typen an variablen zu haben, die unabhaengig von den werten sind, sollte man hier nicht die gefahr eingehen, dass die erwaehnung von typen von variablen in dieser richtung missverstanden wird. Benoetigt wird, wie gesagt, dieses konzept sowieso nicht und definiert ist es, etwa durch ECMA 262, auch nicht.

Man liest auch oft ein "mantra" (jetzt nicht unbedingt auf js bezogen, sondern etwa python, ruby, lisp, aber das modell ist ja bei allen das selbe), das wohl an C-programmierer gerichtet ist und lautet: "variables don't have types, values do". Wird wohl als wert betrachtet, andauernd wiederholt zu werden, um vorurteile und denkblockaden wegraeumen zu helfen.

(Nebenbemerkung: Unter "richtigen" informatikern, welche dynamische typen ueberhaupt nicht als typen ansehen, haben variablen in dynamischen sprachen sehr wohl einen typ, allerdings alle den selben (den man z.b. Any, oder Dynamic nennen koennte), siehe z.b. einleitung von kap. 18 "Dynamic Typing" von [3];  !)

Dass das e bei strenger auslegung nur ein bestimmter ausdruck war, und kein beliebiger, war mir auch aufgefallen, aber ich wollte es nicht noch seltsamer machen, als es so schon war...;)

Bzgl. ausdruck ggue wert: wenn ich "typeof <foo>" schreibe, und das als ausdruck in der sprache meine, dann ist foo eben noch kein wert, sondern auch erstmal ein ausdruck. Vielleicht ist das ohne ein echtes code-schnipsel besser, etwa "typeof ermittelt den typ (eines werts | seines operanden)"... --77.5.190.229 20:49, 20. Jun. 2012 (CEST)

gudn tach!

um es etwas abzukuerzen, gehe ich jetzt nur auf den schluss ein: ja, ich glaube ohne echten code-schnipsel waere das tatsaechlich besser. das ist eine gute idee.

nun gut, von mir aus kannst du es auch gerne direkt im artikel aendern. ich werd's dieses mal nicht revertieren. :-)

das grundsaetzliche thema "datentypen von variablen" waere evtl. mal eine diskussion auf portal:informatik wert. -- seth 22:26, 20. Jun. 2012 (CEST)

Abschnitt Datentypen

Ich bin über den Abschnitt zu Datentypen nicht wirklich froh. Das Verhalten des typeof-Operators und die spracheigenen Typen ohne strikte Unterscheidung zu vermischen ist keine gute Idee [4], instanceof wird übergangen, außerdem ist es falsch, dass sich "mit den vordefinierten Konstruktorfunktionen String(), Number() und Boolean() erzeugte Objekte [...] wie Werte der entsprechenden Datentypen" verhalten. Siehe !!new Boolean(false). Eher "ähnlich wie". Man müsste mal(tm) den Abschnitt klarer fassen. --84.153.56.75 20:08, 25. Jun. 2012 (CEST)

Das seh ich ähnlich. Da Variablen in JS ja (leider) überhaupt nicht typisiert werden können, ist diese ganze typeof-Geschichte eh ziemlich gurkig und gibt nur die primitivsten Basistypen noch dazu in der falschen Großkleinschreibung aus.

Strneg genommen sind auch diese sog. 'Konstruktorfunktionen' eigentlich gar keine (sie werden ja i.d.R. new aufgerufen) sondern eher ein Casting. --Martin Kraft (Diskussion) 20:53, 25. Jun. 2012 (CEST)

Verständlichkeit für Laien (bisher: "JavaScript - Artikel in der wiki")

Das versteht mal wieder kein Mensch.

Warum kann man nicht ganz einfach, ohne kryptisches Fach-Chinesisch beschreiben, was javascript macht, bzw., welche Gefahren sich dahinter verbergen? Warum man,auch unter Verlust der lustigen neuen internet-Welt, auf Java-script verzichten sollte? (nicht signierter Beitrag von Frau.mahlzahn (Diskussion | Beiträge) 02:19, 1. Nov. 2012 (CET))

Du findest den Artikel kryptisch; aber weißt ganz genau, wie man JavaScript mit zwei Sätzen abtun kann. --Parzi (Diskussion) 02:31, 1. Nov. 2012 (CET)

Eine recht eingeschränkte Sichtweise. JavaScript ist schließlich mehr als nur eine im Browser integrierte Sprache. Warum also sollte man generell darauf verzichten? Leider herrschen Meinungen wie Ihre noch in zu vielen Köpfen vor. JavaScript hat inzwischen jedoch mehr Anwendungsgebiete und ist nicht auf den Einsatz in Browsern beschränkt. Ein Paradebeispiel hierfür ist beispielsweise Nodes.js --Dutze (Diskussion) 12:30, 1. Nov. 2012 (CET)

Mal abgesehen davon wäre eine verkürzte Darstellung JavaScript == böse mit dem Neutralitätsgebot der Wikipedia schlicht unvereinbar. --Martin K. (Diskussion) 13:51, 3. Nov. 2012 (CET)

toll, Ihr habt nicht verstanden, was ich meine.--Frau.mahlzahn (Diskussion) 06:05, 13. Nov. 2012 (CET).

Nun rate mal, an wem das liegen könnte! --net (Diskussion) 08:26, 13. Nov. 2012 (CET)

Auch wenn Frau Mahlzahn Ihr Anliegen etwas plump vorträgt: Ich finde dass man zur Verständlichkeit zwei Dinge verbessern könnte.

• Den Einleitenden Absatz für Laien verständlich formulieren, erst danach auf die Charakteristika der Programmiersprache eingehen. Z.B. wie bei "Simple English"
• Den Punkt Sicherheit und Missbrauch zusammenfassen, um den Mythos vom "gefährlichen Javascript" zu entkräften, gleichzeitig aber auch die Rolle JS im Aufspüren von Browser-Sicherheitslücken etc. zu erklären.

PS: Frau Mahlzahn, was meinst du denn? --Jesus Presley (Diskussion) 15:21, 25. Nov. 2012 (CET)

Kasperletheater ;)

var maunz = function () {

  return (lebensZahl > 0) ? "miau" : "örks";

};
Nun, ich weiß ja nicht wie ihr das seht aber das ist mir doch eine Spur zu sehr Gekasper in einer Enzyklopädie. Sollten wir nicht ein etwas seriöses Beispiel finden können? -- Und bevor ich's vergesse: der mit dem "Mutantenfisch" muss wohl am Tag des Eintrags ebenfalls irgendwie zuviel bewusstseinserweiternde Ingredienzien geraucht haben ;)-andy 77.7.11.230 21:38, 31. Dez. 2012 (CET)

Funktionale Sprache?

Es kam gerade eine Rückmeldung, wieso der Artikel denn in der Kategorie "Funktionale Programmiersprache" sei (Spezial:Artikelrückmeldungen_v5/JavaScript#15752). Berechtigt, wie ich finde; JavaScript besitzt zwar (ähnlich wie Perl) Features wie Closures und so weiter, aber es ist dennoch meilenweit entfernt von tatsächlich funktionalen Sprachen wie Haskell oder Erlang, genauso wie Perls Objektorientierung nur schwerlich auf eine Stufe mit, sagen wir, Java gestellt werden kann (ich habe gerade nachgeschaut, Perl ist nicht in der Kategorie "Objektorientierte Programmiersprache"). Vielleicht sollte man den Artikel also aus der Kategorie entfernen - was meint Ihr? --Der Messer ^{meckern? - loben?} 22:05, 11. Feb. 2013 (CET)

Der Definition von Funktionale Programmiersprache folgend, ist JavaScript eine Programmiersprache, „die Sprachelemente zur Kombination und Transformation von Funktionen anbietet“ und gilt somit als funktional. Im Gegensatz zu Haskell ist sie jedoch nicht rein funktional, da auch andere Paradigmen unterstützt werden. --$TR8.$H00Tα ^{talk} 00:12, 12. Feb. 2013 (CET)

Anwendungsbereiche + Missbrauch

Hi, die Beispiele sind meiner Meinung nach ein bisschen seltsam, ich gehe mal von oben nach unten:

"Dynamische Manipulation von Webseiten über das Document Object Model" Tja das bezeichnet ungefähr alles, vielleicht wären da ein paar Beispiele, die der Anwender auch kennt, hilfreicher. Zum Beispiel modale Dialoge oder Lightboxes oder so schnacken.

"Banner oder Laufschriften" Ummm das war mal Flash und heute CSS3 und eigentlich schon immer Bullshit aber hat man dafür jemals flächendeckend Javascript eingesetzt?

"Mehrere Frames auf einmal wechseln oder die Seite aus dem Frameset befreien" Frames in 2013? Ist hoffentlich kein typischer Anwendungsbereich mehr ;

"Ungewolltes Schließen des Browserfensters" Geht nicht.

Gruß, --Courier New (Diskussion) 11:51, 6. Apr. 2013 (CEST)

Nur ein Beispiel: Frames werden massig zum Einbetten von Videos verwendet. Guck z.B. bei YouTube die Codevorschläge. Schliessen geht in manchen Browsern (z.B. Google Chrome) ohne Bestätigungsfenster, wenn keine History vorhanden ist: <html><body><script type="text/javascript">setTimeout("window.close();",4000);</script></body></html> Alauda (Diskussion) 16:16, 6. Apr. 2013 (CEST)

Frames werden bei der google-Bildersuche genutzt - das ist wohl nicht gerade selten. Für Laufschriften, zB. Börsenkurse oder News-Ticker, wird durchaus JavaScript verwendet. JavaScript-Banner-Wechsel-Programme sind zwar seltener geworden, sind aber noch nicht vöällig verschwunden. --Fritzbruno (Diskussion) 16:30, 6. Apr. 2013 (CEST)

Abschnitt zu Traits und Mixins

Ich habe gerade die ausführlichen Ausführungen und Codebeispiele zum Thema Traits und Mixins verworfen, weil diese Pattern meiner Meinung nicht in den Abschnitt Sprachelemente gehören und zudem ihre Beschreibung (insbesondere die Codebeispiele) um ein vielfaches zu lang waren. Das hätte im Artikel nicht nur ein deutliches Ungleichgewicht erzeugt, sondern wäre auch stark richtung Tutorial gegangen - was die Wikipedia ja nicht sein sollte. Gerade Code-Beispile sollte man IMO so kurz und übersichtlich wie möglich halten.

Da es sich bei diesem Thema um einen interessante Alternative zur Vererbung handelt, könnte ich mir trotzdem vorstellen, sie in den zugehörigen Abschnitt zu erwähnen. Allerdings sollte man es dabei bei maximal einem Absatz belassen. --Martin K. (Diskussion) 11:53, 13. Apr. 2013 (CEST)