Diskussion:JavaScript/Archiv/001

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:JavaScript/Archiv/001#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:JavaScript/Archiv/001#Thema_1

Scriptsprache, keine Programmiersprache?

Stimmt das wirklich alles, wie es da steht? Soweit ich weiß, ist JavaScript doch eine Skriptsprache und keine Programmiersprache, und das mit dem objektorientiert ist auch nicht wirklich zwingend. Kann jemand bestätigen, daß die Syntax so ähnlich ist wie die von Java (das ja eine C++-ähnliche benutzt)?

Mein Stand der Dinge war bisher eher:

• Netscape hat JavaScript erfunden, trotz der Namensähnlichkeit hat es aber nicht mit Java zu tun.
• um der Sprache etwas mehr Glaubwürdigkeit zu verleihen wurde sie später der ECMA zur Standardisierung vorgelegt.
• danach wurd sie auch dem W3C vorgelegt, da Microsoft aber inzwischen mit JScript eine eigene Sprache erfunden hatte, wurde keine von beiden zum Standard erhoben, sondern stattdessen ein Standard zur Erstellung von Skriptsprachen entwickelt, der dann zu DOM wurde.

Der letzte Satz ist nicht richtig: DOM heisst Document Object Model und hat mit der Sprache direkt nichts zu tun. Mit der Sprache greift man aber auf die Objekte zu, aus denen ein Dokument aufgebaut ist.

--SoniC

Ich kenn mich da auch nicht aus. Allerdings ist die Syntax ähnlich C und damit Java. Eine Skriptsprache ist auch eine Programmiersprache.

--Vulture

OK, aber Skriptsprache finde ich trotzdem genauer, Programmiersprache klingt immer so nach Informatikstudium :-). Und wie ist das mit den Schnittstellen zu DOM? Kann man das wirklich so schreiben?

Ja siehe http://www.w3.org www.w3.org

--SoniC

Naja, eigentlich ist weder Programmiersprache noch Skriptsprache. (Bei Skriptsprache denke ich hier an Shell-Skripte zum Beispiel.) Dafuer ist sie durch den Browser IMHO rechtlich zu sehr eingeschraenkt. Wie waere es mit "Web-Skriptsprache"?

--Evolux

aalso:

• Syntax ist wie in allen C/C++-Verwandten (wozu neben Java und JS auch noch PHP gehört).
• Erfunden wurde das ganze als "LiveScript" von Netscape, dann in JavaScript umbenannt.
• MS JScript ist im Grunde das gleiche, aber erweitert um einige DHTML-Funktionen und vor allem um Funktionen für das Scripting des Betriebssystems.
• DOM hat mit der Syntax nichts zu tun, wohl aber mit den Objekten in der Sprache. Und eben diese waren anfangs Alternativ zu den JScript-Erweiterungen, heute kann der MSIE beides.
• Netscape selbst hat dem ganzen auch noch einige Objekte verpasst, die nicht in dem ECMA-Standard gelandet sind (document.layers). Diese sind heute ausgestorben.

TheK 19:48, 27. Jun 2004 (CEST)

--MatthiasSchulze

Habe Details zu Vererbung und Prototypen ergänzt. So ok?

--XRay 14:26, 24. Dez 2004 (CET)

Umlaute

Die Umlaute aus den Beispielskripten habe ich ersetzt, da dies in den Skripten bzw. XHTML- oder HTML-Seiten zu Problemem (oder Fehlern) führen könnte, zum Beispiel abhängig davon, ob jemand ISO-8859-15 oder UTF-8 als Zeichensatz nutzt.

Zu dem Umlauten in Kommentaren etc. Ja, Umlaute dürfen auftreten, sie müssen nur mit dem Zeichensatz passen. Probleme gibt es in der Regel dann, wenn man zum Beispiel XHTML-Dateien erstellt, diese mit UTF-8 verfasst, dann aber Umlaute in ISO-8859-1 einbringt. Daher gehe ich eher den Weg, Umlaute zu vermeiden.

Wie geht es weiter mit dem Abschnitt »Datenstrukturen und Objekte«?

Ich frage mich, welche Objekte bzw. Eigenschaften und Methoden dort genannt werden sollen. Worauf gründet sich die Auswahl der dort aufgelisteten? Momentan ist die Liste sehr bunt und folgt keinem Schema. Es sind einige ECMAScript-Objekte genannt, nämlich Array, String, Date und Math. Deren Eigenschaften und Methoden sind aber nicht annähernd vollständig genannt, es fehlen oft gebrauchte, während selten gebrauchte genannte sind. Von den ECMAScript-Standardobjekten fehlen z.B. Boolean, Number und RegExp. Welchen Sinn hat es, überhaupt einige willkürliche Objekte aus ECMAScript zu nennen? Für die spärliche Dokumentation der in Netscape-JavaScript eingeführten Objekte gilt das umso mehr. Warum gerade von window diese drei Funktionen und warum gerade das screen-Objekt? Unter »Function Objekt« ist dann ein Beispiel für eine Function-Expression aufgeführt, die dort wenig zu suchen hat (d.h. genauso viel, wie ein gewöhnliches Function-Statement, denn das erzeugt auch Function-Objekte). Können wir da irgendwie eine sinnvolle Ordnung hineinbringen? Ich persönlich sehe für eine Enzyklopädie wenig Sinn in einer notorisch unvollständigen Dokumentation von ein paar willkürlich ausgesuchten Objekten. Ich würde den Teil auf ein Minimum streichen, aber ich frage lieber vorher hier. Das hieße allgemeinere Erklärungen, was die ECMAScript-Objekte darstellen (Prototypen-Objekte für Datentypen- und strukturen) und welche Objekte in JavaScript das Rückgrat bilden (window, document, location usw.). --molily 03:34, 24. Feb 2005 (CET)

"Mittlerweile wurden auf dieser Basis zusätzlich normale Klassen implementiert, wohl in der Annahme, damit den Einstieg zu erleichtern." Das ist so nicht richtig. Weder die aktuelle JavaScript Version (1.5) noch der aktuelle ECMAScript Standard 262 (dritte Version) kennen Klassen. (=> evtl. einfach Streichen?)

Außerdem würde ich vorschlagen alles was nicht Teil der JavaScript/ECMAScript Sprachen an sich ist zu entfernen (verschieben). Also insbesondere Objekte die Teil einer "Host Umgebung" sind. (Sprich Browser DOM Objekte wie window)

Zu den privaten Eigenschaften (JavaScript spezifisch wegen __parent__): function Foo(){var priv=1;this.get=function(){return priv;}}; var foo=new Foo();alert(foo.get());foo.get.__parent__.priv=10;alert(foo.get());

--Unbekannt (anm. elias)

JavaScript bezieht sich eigentlich immer auf den ECMA-262 Standard. Deswegen sollte diese Seite erstmal diesen Standard behandeln und frei von den proprietären Implementierungen beschreiben. Zusätzlich kann ein Kapitel wie zb "Javascript und Browser" eingeführt werden, wo wichtige Unterschiede oder Implementierungen beschrieben werden.

$elias 17:37, 16. Mai 2005 (CEST)

Da möchte ich teilweise widersprechen. »JavaScript« bezeichnet die Konvention, die sich nach der Erfindung von Netscapes (clientseitigem) JavaScript breit durchgesetzt hat (von serverseitigem JavaScript einmal abgesehen). Dies umfasst etwa window als Hostobjekt, document, location usw. (Strenggenommen sind diese Objekte allesamt nach wie vor proprietär, weil sie nie konsensuell standardisiert wurden.) Unter dem Stichwort JavaScript sollte daher auch vornehmlich dieses JavaScript beschrieben werden. Falls wir ECMAScript als solches möglichst allgemein und gesondert beschreiben wollen, dann sollte das unter dem Lemma ECMAScript passieren (momentan eine Weiterleitung zu JavaScript). Es gibt nämlich mehrere ECMAScript-Anwendungen. Z.B. in der englischen Wikpedia ist en:ECMAScript ein eigenständiger Artikel, wenngleich die Beschreibung der Sprache in en:JavaScript residiert. --molily 17:32, 17. Mai 2005 (CEST)

Ja du hast recht, da lag ich Falsch. JavaScript ist schon eine konkrete Implementierung. Aber man könnte zb bei Datentypen, Kontrollstrukturen etc die im Standard definiert sind auf ECMAScript verweisen und ggf. dann nur die proprietären Elemente beschreiben. Ich hab hier schon eine kleine Einleitung für einen ECMAScript Artikel geschrieben die von englischen Äquivalent und dem ECMA-262 Dokument inpiriert sind. Werde versuchen das diese Woche noch brauchbar zu machen. $elias 20:13, 17. Mai 2005 (CEST)

Alles neu?

Mit Verlaub, aber ich empfinden diesen Artikel als ein Vorzeigebeispiel, wie man es nciht machen soll. Die Kontrollstrukturen im Einzelnen zu behandeln, oder konkrete Listen von Methoden sind kein enzyklopädischer Stil. Sogar der Abschnitt "Geschichte" ist eine Liste. Wie wäre es mit einem Entwurf für einen Neustart? --Pjacobi 14:41, 22. Mai 2005 (CEST)

Obwohl ich den Artikel mit vielen Edits korrigiert habe, habe ich mich bisher gehütet, die Struktur zu verändern und von anderen eingefügte Abschnitte und Inhalte zu streichen. Dass der Artikel zu einer Art Tutorial geworden ist, habe ich oben schon kritisiert.

Wenn es nach mir ginge, würde ich folgende Bereiche komplett streichen, da sie m.E. der Aufgabe einer Enzyklopädie widersprechen: Die Beschreibung der Kernobjekte im Einzelnen, Kontrollstrukturen, Private Eigenschaften, Benutzerinteraktion, Fehlerbehandlung. Von Funktionen den Teil bis Konstruktor-Funktionen. Den Rest von Funktionen und Vererbung würde ich in einen Abschnitt einarbeiten, der die Besonderheiten von JavaScript beleuchtet (Funktionen sind Objekte und was daraus folgt; Prototypische Vererbung). Geschichte kann man weitesgehend eindampfen, diese Listen stehen auch woanders im Netz (Quelle ist AFAIK sowieso http://www.mintert.com/javascript/).

Da offenbar viele die jetzige Herangehensweise bevorzugen, fürchte ich, dass ein solcher radikaler Edit nur Reverts nach sich ziehen würde?! -- molily 18:39, 22. Mai 2005 (CEST)

Vielleicht sollte man statt groß drumherumzureden mal den Artikel wirklich umkrempeln. Wikipedia ist ein Enzyclopädie und ich finde das so weiter gehende Sachen wie Fehlerbehebung etc. rausgelassen werden sollten , da mich das jetzt eher an eine Einführung in JavaScript erinnert. Es gibt andere Internetangebot wie Selfhtml wo das näher erklärt wird, daher muss das nicht in einem Wikipedia Artikel stehen. -- Crossroad 18:18, 20. Okt 2005 (CEST)

ist JS objektorientiert?

Die Behauptung, dass JavaScript eine OOP Sprache darstellen soll, ist falsch. Es fehlen die typischen objektorientierten Ansätze wie Polymorphie, Abstrakte Basisklassen, sowie Interface-Klassen. In der Fachliteratur spricht man von einer objektbasierenden Sprache mit objektorientierten (siehe Professional Javascript 2ND Edition der P2P Serie) Ansätzen, welche aber lange nicht zu Ende geführt sind. So zum Beispiel die Scope/Context-Strategie von JavaScript, welche jedem sauberen OOP-Ansatz wiederspricht. Die Sourcen des Rhino-Projektes (JS-Parser/Interpreter des Mozillas) zeigen diese gravierenden Unterschiede zu OOP sehr deutlich.

Meines Erachtens sollte diese Stelle sofort aus dem Wiki entfernt werden, da diese zu Verwirrung führt und schlussendlich dem Benutzer eine fehlerhafte Information liefert.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 1. Nov 05

nee, die kriterien was OO ist und was "nur" objektbasierend sind in der fachliteratur höchst unterschiedlich dargestellt. abstrakte basisklassen und interface-klassen sind jedenfalls kein allgemein akzeptiertes kriterium für "echte" OO. was du genau unter "Scope/Context-Strategie" verstehst und inwiefern das einem OOP-ansatz wiederspricht ist mir auch nicht ganz klar.. -- ∂ 22:21, 1. Nov 2005 (CET)

Soviel zum Thema "Was ist OOP": <http://www.uni-koeln.de/rrzk/kurse/unterlagen/oopintro/general/begriffe.htm> Vielleicht solltest du dies einmal überfliegen, denn ohne Abstrakte Basisklassen, sowie Interface-Klassen gibt es keine Polymorphie im Sinne von OOP - Ohne Polymorphie kein OOP. Zudem werden bei der JavaScript prototype-Vererbung nur die Wertetypen kopiert; bei Referenztypen wird der Zeiger auf ein Objekt kopiert; dies ist nicht im Sinne von OOP. Die Scope/Context-Strategie ist ein Basiskonzept von EcmaScript (siehe <http://www.ecma.ch> unter ECMA-262 Standard), welches die einzelnen Scopes (Variablenzugriff in den Verschachtelungsebenen - Chained-Scopes) beschreibt. Einen globalen Scope (this-Ptr auf globales Wnd-Objekt), wie JavaScript über einen verfügt, ist vor allem bei objektbasierenden Scriptsprachen anzutreffen. Auf jeden Fall kann JavaScript keine OOP-Sprache sein: Mein Korrekturvorschlag: "JavaScript ist eine objektbasierende Web-Skriptsprache mit objektorientierten Ansätzen. Ursprünglich wurde JavaScript von der Firma Netscape unter dem Namen LiveScript entwickelt, um statische HTML-Seiten dynamisch zu gestalten."

Anmerkung: Siehe en-Artikel: <http://en.wikipedia.org/wiki/JavaScript>

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 2. Nov 05

habe mir den link oben mal angesehen, der mir doch sehr C++-lastig vorkommt, und da steht zu lesen: Im Zusammenhang mit OOP meint Polymorphie genau das, was der obige Abschnitt beschreibt: daß ein Pointer (eine Referenz) auf Objekte verschiedenen Typs zeigen kann und die gleiche Message je nach Objekttyp eine andere, spezifische Reaktion hervorruft.. ein "interface-klasse" - komisches wort, eine klasse hat ein interface (=schnittstelle), aber sie ist keines - braucht man dazu mit sicherheit nicht. wenn ich zwei JS-objekte habe die die selbe message verstehen und unterschiedlich darauf reagieren, also zwei unterschiedliche, aber gleichnamige methoden haben, dann passiert genau das im zitat beschriebene: abhängig vom objekttyp wird mal die eine, und mal die andere methode aufgerufen. du darst dabei nur nicht den fehler machen, typ und klasse zu verwechseln.

chained scopes gibt es (eingeschränkt) übrigends auch in java - da muß man halt noch eine inner class drumrum packen und es wird "magisch" ein zweiter this-pointer erzeugt. damit, daß es einen globalen scope hat, ist JS sicher keine strikt objektorientierte sprache mehr, aber der eigentlich wichtige punkt "alles ist ein objekt" wird davon nicht berührt. -- ∂ 14:20, 4. Nov 2005 (CET)

Ein gravierendes Problem an der objekt basierenden Implementation von JavaScript ist, dass der mitgelieferte Vererbungsalgo nicht dem einer OOP-Vererbung entspricht (siehe oben). Weiterhin steckt hinter einem Objekt irgend etwas (void-ptr in C++). Vielliecht ist ein Hund oder ein Vogel dahinter; solltest du auf dem Hund *fliegen()* aufrufen, gibts einen Fehler; d.h. es gibt keine Interfaces, was OOP allerdings vorschreibt (Design-Patterns basieren stark darauf). Wie möchtest du denn sichergehen, dass eine Methode auf einem Objekt existiert? Immer den fnc-Pointer abfragen? Dies sollte ja gerade OOP verhindern. Aber whatever, es scheint eher eine Glaubensfrage zu sein, als eine Sachfrage; wie du ja auch schreibst, ist JS sicher keine strikt objektorientierte Sprache, daher sollte man JavaScript auch nicht so verkaufen.

Meiner Meinung nach ist JavaScript sehrwohl objektorientiert. Lediglich wird die eher "unpopuläre" Prototypen-Vererbung eingesetzt und nicht die bekanntere Klassen-Vererbung! Dubaut 13:36, 7. Mär 2006 (CET)

Der in englisch verfasste Artikel ist mir wesentlich sympatischer.

P.S: ein "interface-klasse" - komisches wort - Ein Interface ist eine besondere Form einer Klasse, die ausschliesslich abstrakte Methoden und konstante Eigenschaften enthält. Um eine Interface-Klasse zu kennzeichnen, wird meist ein I-Prefix vor den Klassennamen geschrieben: IDataProvider.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 7. Nov 05

was an dem "vererbungsalgo" nicht oop sein soll ist mir immer noch nicht klar, sorry. wenn du den lexikalischen lookup meinst: den haben andere auch.

daß hinter jedem objekt "irgendwas" steckt, also Duck Typing verwendet wird, ist kein argument: Smalltalk (Programmiersprache), die OO-sprache überhaupt, hat auch keine typisierten referenzen. du gehst einfach gar nicht sicher, ob es die methode gibt - dafür hat smalltalk die methode doesNotUnderstand.

ein paar desing-patterns mögen darauf basieren, aber die sind dazu da spezifische probleme mit bestimmten sprachen zu lösen, definieren aber sicher nicht, was OO ist und was nicht.

nochmal zurück zum "komischen wort": eine klasse besteht aus einem interface und einer implementierung, aber sie ist kein interface. klar, java ist weiter weil man interfaces unabhängig von der implementierung definieren kann. dummerweise geht es umgekehrt nicht, eine klasse bringt immer implizit auch ein interface mit, diese trennung ist in modernen sprachen wie Sather klarer.

wie ich schon sagte, ist die definition was OO ist extrem umstritten - und JS erfüllt meiner meinung nach die wichtigsten kriterien durchaus. überzeug mich, daß dem nicht so ist, aber verwechsle nicht Statisches Typing mit OO! -- ∂ 22:18, 12. Nov 2005 (CET)

GRINS, ich glaube nicht, dass man dich noch vom Gegenteil überzeugen kann ;). Dies ist auch nicht wirklich mein Ziel :D. Zum lexikalischen Lookup (bei JS prototype-Vererbung): In JavaScript werden bei der Vererbung die Referenztypen nicht neu kreiert sondern einfach die Referenz kopiert. Beispiel:

function Wheel() { }

function Car()
{
  this.color = "red";
  this.wheels = [ new Wheel(), new Wheel(), new Wheel(), new Wheel() ];
}

function Ford()
{
  // beinhaltet color = "red"
  // enthält eine neue referenz von wheels[]
};
Ford.prototype = new Car();

function Mustang()
{
  // beinhaltet color = "red"
  // beinhaltet eine referenz zu wheels[] in Ford (gleiche Referenz wie Focus hat -> keine *echte* Vererbung)
};
Mustang.prototype = new Ford();

function Focus()
{
  // beinhaltet color = "red"
  // beinhaltet eine referenz zu wheels[] in Ford (gleiche Referenz wie Mustang hat -> keine *echte* Vererbung)
};
Focus.prototype = new Ford();


// kreiere Instanzen
var focusInstance = new Focus();
var mustangInstance = new Mustang();
alert(focusInstance.wheels == mustangInstance.wheels); // gibt true aus

Ob diese merkwürdige Eigenschaft einer OO-Implementierung in JS einzigartig ist, kann ich nicht beurteilen. Es entspricht meiner Meinung nach keiner OO-Vererbung, viel eher einem Ansatz einer OO-Implementierung, welcher nicht zu Ende geführt wurde. In einem Punkt sind wir gleicher Meinung: Die definition von OO ist extrem umstritten und statisches Typing ist nicht erforderlich. Aber wenn man in einer *strikten* OO-Sprache vor jeden Fnc-Call ein if (typeof(obj.someThingIsThere) == 'Function') {} (ansonsten gibts einen Fehler) schreiben muss, dann mag sein, dass die Sprache zwar im Grundsatz nach den OO-Regeln implementiert wurde, allerdings nicht alle Sprachdefinitionen den OO-Anforderungen (siehe C++/Java/C#/...) entsprechen. Wenn JS über eine doesNotUnderstand() methode verfügen würde, wären wir auch in diesem Punkt gleicher Meinung.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 13. Nov 05

Seltsame OOP-Definition, wie schon gesagt, würde dies ja auch Smalltalk (Programmiersprache), Self (Programmiersprache), CLOS ausschliessen. Bloss nicht die Links anklicken! Anscheinend sind fast alle unsere Programmiersprechenartikel sehr kurz oder sehr seltsam. --Pjacobi 15:00, 14. Nov 2005 (CET)

Generell zu deiner Aussage: Ich finde WIKI grossartig, es ist eine feine Sache, das Wissen weltweit gratis zur Verfügung zu stellen; habe das Projekt auch schon mehrfach donated. Allerdings sollte der Inhalt korrekt sein, d.h. nach dieser Diskussion kann man konkret Punkte für und gegen JavaScript verfügt über OOP auflisten (QS). Wie schon gesagt, ob andere Programmiersprachen auch über eine derartige Implementation der Vererbung verfügen, kann ich nicht beurteilen, da ich mit C++/Java/C-Sharp aufgewachsen bin. Es widersprach einfach allem bisher Gelernten über OOP, daher habe ich es hier aufgelistet. Ob nun JavaScript wirklich OO ist, sollte man den Leser entscheiden lassen, da deutliche OO-Sprachelemente vorhanden sind, allerdings auch widersprüchliche Elemente existieren.

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 14. Nov 05

Wie etwas implentiert ist, ist doch egal. Dass C++ als Preprozessor für C implementiert werden kann, spricht ja auch nicht dagegen, dass C++ eine OOP ist. Allerdings fehlen C++ eine Eigenschaft in Bertrand Meyers Liste (in ISBN 0136290310), um als vollwertige OOP zu gelten: Das automatische Deallozieren von nicht länger benutzten Objekten. --Pjacobi 20:16, 14. Nov 2005 (CET)

Okay GRINS... ich werde den Link mit dem Zaunpfahl nutzen und mir das beschriebene Buch zu gemüte führen, thx. Was schliessen wir nun aus dieser Diskussion? Mein Vorschlag: "JavaScript ist eine Web-Skriptsprache mit objektorientierten Ansätzen..." :)

--Mcdark (prj-admin <http://jstoolsdotnet.tigris.org>) 14. Nov 05

M.E. ist die Aussage, dass JavaScript im Gegensatz zu klassisch objektorientierten Sprachen keine Klassen einsetzt, sondern statt dessen Objekte als Prototypen verwendet bereits recht treffend. Vielleicht sollte man noch ergänzen (falls es in diesem grausamen Artikel nicht schon irgendwo steht), dass die Benutzung der OO-Merkmale optional ist (wie auch bei C++). In der Anfangszeit der OOP hielt man es ja manchmal für besser, in einer Art Erziehungsdiktatur diese Entscheidung dem Programmierer abzunehmen. --Pjacobi 21:14, 14. Nov 2005 (CET)

Version/Autoren; Zitat Molily K: (rev. welche merkmale von OOP Javascript hat und nicht, wäre an anderer stelle genauer zu klären. aber nicht bereits den ersten satz zerhacken! vielleicht einigt man sich mal auf der diskussionsseite)

Es ist eine Einigung im Sinne aller Beteiligten zu stande gekommen: JavaScript ist weder 100% OOP noch kann man von absolut objektbasierenden Eigenschaften sprechen. Man kann also die Aussage wagen, dass JavaScript objektorientiert ist, da auch andere Sprachen (z.B. C++) nicht alle Anforderungen an OO erfüllen (GC-Problem), aber trotzdem als OO-Sprachen bezeichnet werden. Die Aussage, JavaScript sei objektbasierend, ist ebenfalls korrekt, da JavaScript nicht alle OO-Anforderungen erfüllt und zudem klare Merkmale einer prozeduralorientierten Sprache aufweist. Es ist also eine Gratwanderung und man wird es nicht zu 100% festlegen können. Daher ist es schlussendlich eine Glaubensfrage, dies ist auch aus der gängigen JavaScript-Literatur deutlich ersichtlich. Der erste Satz ist also auf das Zielpublikum anzupassen; will man eher dem allgemeinen Ruf von OO (JavaScript ist OO) oder der Definition von OO (JavaScript ist objektbasierend <http://en.wikipedia.org/wiki/Object-based>) Beachtung schenken.

--Mcdark (prj-admin <http://www.jstools.net>) 15. Dec 05

Ich bin gerade zufällig auf den Artikel gestoßen. Meine Meinung: bei Objektorientiertheit gibt es Abstufungen. Da schließ ich mich Mcdark an. Da ist zum einen Smalltalk als absolut objektorientiert, dann C++ und Java, die es schon nichtmehr ganz so eng sehen. Man könnte vielleicht als Kompromiss schreiben, dass in JavaScript objektorientiert gescriptet werden kann. AccountAlive

Alles neu!

PHP als Vorlage-Artikel.

PHP ist nicht exzellent, aber sehr brauchbar und allgemeinverständlich. JavaScript und PHP lassen sich in punkto Verbreitung und Bedeutung schon miteindander vergleichen. Ein Artikel über JavaScript muss keineswegs länger sein als einer über PHP!

Gliederungs-Vorschlag

Definition, Stichworte

Browser, Internet: Verbreitung, dynamisches HTML, Scriptsprache,

1. Geschichte (Neu schreiben. Tabelle bringt nix. Im übrigen ist die Geschichte nicht gerade unspannend.)
2. Verwendung
   1. wofür wird Javascript normalerweise verwendet
   2. was geht sinnvollerweise nur mit Javascript (zwei Frames gleichzeitig öffnen, <form action""> ändern, Plausibilitätsprüfung von Formularen...)
   3. was geht nicht mit Javascript (Passwort)
   4. einfache Beispiele
   5. Leistungsfähigkeit: Groß-Projekte und kommerzielle Produkte auf JavaScript-Basis
   6. Missbrauch
3. Sicherheit
   1. Sandbox-Prinzip
   2. Exploit-Geschichte. Stand (aktuell)
   3. Wie kann man's abschalten?
4. Besonderheiten beim Programmieren mit Javascript
   1. Cross-Browser, debugging
   2. Objekte: wie eine HTML-Seite in Objekte zerlegt wird (vor und nach DOM)
   3. Interaktion: der event-handler
5. Schnittstellen (Stellung zu anderen Techniken)
   1. HTML: im Code (z.T. im Tag: onMouseover), als separate Datei
   2. "dynamisches HTML"
   3. CSS
   4. ActionScript (Macromedia)
   5. JScript
   6. Server seitiges Javascript
   7. Verhältnis server- und cliente-seitige Scripts - Interaktion.
6. Sprachelemente
   • Da käme stark zusammen-kondensiert rein, was z.Z. unter Punkt 2 bis 11 steht. Prinzip: "Kontrollstrukturen sind die selben wie bei...", mit externen Links, z.B. zu SelfHTML
7. Weblinks

Ist bislang das einzige Unterkapitel, das halbwegs was taugt.

Begründung

In meiner Hitliste schlechter Wiki-Artikel ist JavaScript ganz oben. Die Autoren haben sich wohl kaum Gedanken darüber gemacht, an welchen User sich der Artikel richten soll. Ist es niemandem in den Sinn gekommen, dass hier ganz normale Internet-User nachschauen wollen, ob sie in ihrem Browser Javascript aktivieren oder deaktivieren sollten? Oder dass ein Programmierer, der sich nicht mit JavaScript auskennt, einen Eindruck gewinnen möchte, was die Sprache kann, und was nicht?

Bei der Definition haben sich Autoren heftigste Gedanken gemacht, ob Javascript denn eine Programmiersprache ist. Wo's drauf ankäme, dass das Zeugs vom BROWSER interpretiert wird, steht da: JavaScript auf dem Client ausgeführt. Ja, das wird M$-Word und der Acrobat-Reader auch.

Oder folgender Schmonz: "Mittels einer Schnittstelle zum Document Object Model (DOM) können Elemente der Webseite manipuliert werden, nachdem diese zum Client übertragen wurden."

• Elemente einer Webseite "manipuliert"?? Mit document.write war Javascript schon unter Netscape 2 (bei 3 weiss ich's sicher) in der Lage, komplette Webseiten zu generieren, PopUps zu öffnen, etc. etc.
• "Mittels einer Schnittstelle zum Document Object Model" ist auch so ein Käse. Die Forumular-Elemente wurden von Javascript schon immer "manipuliert", einen <input type=""hidden"> gibts wahrscheinlich nur zu dem Zweck, dass dort Werte per Javascript geändert werden.

Statt dessen wird hier so eine Art vergleichende Semantik am Beispiel Javascript abgehandelt - fernab von brauchbarer Theorie und vor allem Praxis. Wo es beim Javascript-Programmieren tatsächlich darauf ankommt, den Code ständig mit den aktuellen Browsern zu testen und Debugger einzusetzen, steht da was über try...catch...schnarch...

Überflüssige Details raus!

Ein neues Element an das Ende des Array anhängen. Derlei gehört, wenn überhaupt in das Lemma arrays. (Ich verwende ständig arrays, habe diese Funktion aber weder in PHP, geschweige denn in Javascript jemals gebraucht.)

Stilistisches

• Allen Objekten können zur Laufzeit neue Eigenschaften hinzugefügt. Wann denn sonst??? Wir reden hier über eine Scriptsprache!
• Switch-Kontrollstruktur etc: Quellcode ohne jede Erläuterung. Gehört sowieso nicht hierher, sondern in das Lemma Switch. Und unkommentiert gehörts nirgendwo in Wikipedia rein.
• "Interessant ist die Tatsache, dass JavaScript im Gegensatz zu klassisch objektorientierten Sprachen keine Klassen einsetzt, sondern statt dessen Objekte als Prototypen verwendet.".
  Eigentlich hats mich ja nicht interessiert, was Prototypen sein sollen, aber als ich unter dem Lemma Prototyp nachgesehen habe...

Fazit

• auf einer anderen Seite komplett neu bauen
• Löschantrag für die alte Version
• ersetzen

--Asw-hamburg 03:59, 2. Nov 2005 (CET)

Die Gliederung sieht bis auf einige Schwachstellen sehr brauchbar aus - den Vergleich zum Artikel PHP verstehe ich aber nicht, die Gliederung geht über den (m.E. überhaupt nicht vorbildhaften PHP-Artikel) zum Glück hinaus.

Im Detail scheinst du in eine fragwürdige Richtung zu wollen. Ist es niemandem in den Sinn gekommen, dass hier ganz normale Internet-User nachschauen wollen, ob sie in ihrem Browser Javascript aktivieren oder deaktivieren sollten? Wikipedia ist aber keine Howto-Sammlung. Daran krankt der Artikel doch gerade! Ein Artikel zu JavaScript muss nicht die Frage Wie bediene ich meinen Browser beantworten, genausowenig wie er dem Leser JavaScript beibringen kann.

Deine Kritik am Satz zum DOM verstehe ich nicht. Was soll der Vergleich zu document.write? Operationen am Knotenbaum mit W3C-DOM ist eine komplett andere Geschichte als das primitive DOM von Netscape Client Side JavaScript, das das Ändern von Formularfeldern erlaubt. Manipulation meint etwas ganz anderes, nämlich ein beliebiges Ändern des Knotenbaums. Nein, das geht nicht mit konventionellem JavaScript. Und <input type="hidden"> ist auch nicht nur für JavaScript geschaffen worden.

-- 83.129.36.29 20:28, 3. Nov 2005 (CET)

Zu Besonderheiten beim Programmieren mit Javascript:

Cross-Browser, debugging - Was auch immer damit gemeint ist? Bitte nicht erklären, wie man JavaScripte debuggt, sondern allgemein die Problematik der browserübergreifenden und kompatiblen Verwenden von Objekten usw.

'Objekte: wie eine HTML-Seite in Objekte zerlegt wird (vor und nach DOM) - Darunter kann ich mir nichts vorstellen, was ist gemeint? Kurze Erklärung des DOM Core/DOM HTML?

Interaktion: der event-handler - Die Erläuterung des Event-Handlings sollte eher schon am Anfang unter Verwendung geklärt werden, wie die gesamte Einbettung in HTML und Zusammenarbeit mit HTML. Man kann ja nicht in Abschnitt 2 die Verwendung schildern, aber erst in Abschnitt 4 beschreiben, wie JavaScript-Logik in ein HTML-Dokument eingeflochten wird.

Sachverhalte wie das Sandbox-Prinzip sollten schon relativ am Anfang (zumindest einführend) angesprochen werden, wo der Einsatzbereich und die Fähigkeiten/Ziele von JS grundlegend umrissen werden. -- molily 20:47, 3. Nov 2005 (CET)

Lob zu Abschnitt 12

Hallo,
ein Lob an den/die Schreiber des Artikels für Abschnitt Zwölf! Genau dieses Thema (Eigene Objektmethoden, Vererbung durch Prototyping), einfach erklärt, hab ich anderswo vergeblich gesucht.
(Negativbeispiel ist Selfhtml. Doku schweigt sich aus, der Feature-Artikel ist fehlerhaft).

Vorschlag: Wir machen aus diesem Artikel ein Wikibook, und schreiben für die Enzyklopädie eine neue, verkürzte Version. Aber bitte nicht löschen, wäre echt schade.

--Nils Holgerson 14:09, 12. Mär 2006 (CET)

(Eigentlich etwas früher, aber grade erst das mit den Tilden gecheckt)

Stimmt das wirklich alles, wie es da steht? Soweit ich weiß, ist JavaScript doch eine Skriptsprache und keine Programmiersprache, und das mit dem objektorientiert ist auch nicht wirklich zwingend. Kann jemand bestätigen, daß die Syntax so ähnlich ist wie die von Java (das ja eine C++-ähnliche benutzt)?

Mein Stand der Dinge war bisher eher:

• Netscape hat JavaScript erfunden, trotz der Namensähnlichkeit hat es aber nicht mit Java zu tun.
• um der Sprache etwas mehr Glaubwürdigkeit zu verleihen wurde sie später der ECMA zur Standardisierung vorgelegt.
• danach wurd sie auch dem W3C vorgelegt, da Microsoft aber inzwischen mit JScript eine eigene Sprache erfunden hatte, wurde keine von beiden zum Standard erhoben, sondern stattdessen ein Standard zur Erstellung von Skriptsprachen entwickelt, der dann zu DOM wurde.

Der letzte Satz ist nicht richtig: DOM heisst Document Object Model und hat mit der Sprache direkt nichts zu tun. Mit der Sprache greift man aber auf die Objekte zu, aus denen ein Dokument aufgebaut ist.

--SoniC

Ich kenn mich da auch nicht aus. Allerdings ist die Syntax ähnlich C und damit Java. Eine Skriptsprache ist auch eine Programmiersprache.

--Vulture

OK, aber Skriptsprache finde ich trotzdem genauer, Programmiersprache klingt immer so nach Informatikstudium :-). Und wie ist das mit den Schnittstellen zu DOM? Kann man das wirklich so schreiben?

Ja siehe www.w3.org|http://www.w3.org www.w3.org

Ich habe das früher auch so gesehen, aber seit ich mir das umfassende Werk von O'Railly zu gemüte geführt hat, erinnert mich JavaScript auch immer mehr an Informatikstudium. Dubaut 13:32, 7. Mär 2006 (CET)

--SoniC

Naja, eigentlich ist weder Programmiersprache noch Skriptsprache. (Bei Skriptsprache denke ich hier an Shell-Skripte zum Beispiel.) Dafuer ist sie durch den Browser IMHO rechtlich zu sehr eingeschraenkt. Wie waere es mit "Web-Skriptsprache"?

--Evolux

aalso:

• Syntax ist wie in allen C/C++-Verwandten (wozu neben Java und JS auch noch PHP gehört).
• Erfunden wurde das ganze als "LiveScript" von Netscape, dann in JavaScript umbenannt.
• MS JScript ist im Grunde das gleiche, aber erweitert um einige DHTML-Funktionen und vor allem um Funktionen für das Scripting des Betriebssystems.
• DOM hat mit der Syntax nichts zu tun, wohl aber mit den Objekten in der Sprache. Und eben diese waren anfangs Alternativ zu den JScript-Erweiterungen, heute kann der MSIE beides.
• Netscape selbst hat dem ganzen auch noch einige Objekte verpasst, die nicht in dem ECMA-Standard gelandet sind (document.layers). Diese sind heute ausgestorben.

TheK 19:48, 27. Jun 2004 (CEST)

--MatthiasSchulze

Wie ihr seht sind die Unterschiede zwischen Programiersprache und Scriptsprache schwer zu definieren, deswegen würde ich darauf garnicht rumreiten und es evtl. nur Beiläufig erwähnen. Viel wichtiger wäre zu erwähnen das JS eine interpretierte Sprache ist.

$elias 17:37, 16. Mai 2005 (CEST)

Habe Details zu Vererbung und Prototypen ergänzt. So ok?

--XRay 14:26, 24. Dez 2004 (CET)

Die Umlaute aus den Beispielskripten habe ich ersetzt, da dies in den Skripten bzw. XHTML- oder HTML-Seiten zu Problemem (oder Fehlern) führen könnte, zum Beispiel abhängig davon, ob jemand ISO-8859-15 oder UTF-8 als Zeichensatz nutzt.

Zu dem Umlauten in Kommentaren etc. Ja, Umlaute dürfen auftreten, sie müssen nur mit dem Zeichensatz passen. Probleme gibt es in der Regel dann, wenn man zum Beispiel XHTML-Dateien erstellt, diese mit UTF-8 verfasst, dann aber Umlaute in ISO-8859-1 einbringt. Daher gehe ich eher den Weg, Umlaute zu vermeiden.

Artikel droht auszuufern

Es werden immer mehr irrelevante Details eingefügt, anstatt die Substanz zu erneuern - könnt ihr euch bitte an der Diskussion beteiligen (siehe oben), damit eine vernünftige Lösung gefunden wird? -- molily 7. Jul 2005 11:14 (CEST)

Ich möchte mich dem anschliessen! Viiiel zu viiiel! Schon auf den ersten Blick erschlagen einen zuviele Details, die nicht in die Wikipedia gehören. (Wurde hier alles schon irgendwie gesagt.) --83.135.5.126 20:41, 30. Aug 2006 (CEST)

Als zufällig vorbeikommender User kann ich über die seite folgendes sagen: diese seite hat (vor allem gegen den schluss hin) nichts mehr mit einem artikel, der in eine enzyclopedie gehört, zu tun. es gleicht mittlerweile mehr einer einführung in die scriptsprache. z.T. werden Details wie das try-catch-finally konstrukt erklärt. daher: wäre super wenn sich jemand die mühe macht, den artikel zu entrümpeln. --212.241.81.152 14:40, 6. Sep 2005 (CEST)

Beifall und Zustimmung. Nur ein Beispiel: Hier wird sogar die Objektorientierung erklärt, im Abschnitt "Öffentliche und private Methoden und Eigenschaften" zB. Das hat hier tatsächlich nichts zu suchen . -- Benutzer:60.234.145.15

»Sogar« ist witzig. Objektorientierung ist eine der wichtigsten Eigenheiten von JavaScript. In dem besagten Abschnitt wird sicher das allgemeine OO-Konzept der Kapselung beschrieben - aber jeweils mit speziellem Bezug auf JavaScript. Wo bitte ist das in der Wikipedia verständlich und mit Praxisbezug beschrieben, sodass es der Leser auf JavaScript übertragen könnte? Objektorientierte Programmierung#Kapselung bleibt vollkommen allgemein. Da steht eben: Die Möglichkeiten zur Spezifizierung der Zugreifbarkeit sind je nach Programmiersprache unterschiedlich. Der kritisierte Abschnitt soll daran anknüpfend die JavaScript-spezifische Kapselung beschreiben. OO-Sprachen wie JavaScript mit Prototypen, prototypischer Erweiterung, Konstruktorfunktionen, Funktionsobjekten usw. werden im Artikel Objektorientierte Programmierung überhaupt nicht bedacht. JavaScript ist in dieser Hinsicht auch ziemlich einzigartig, sodass die Übertragung von allgemeinem OOP-Wissen (Klassen und Co.) schwer ist.

"Objektorientierung ist eine der wichtigsten Eigenheiten von JavaScript" ???

Javascript ist wohl das blödeste Beispiel für OOP. Ob ins Lemma Objektorientierte Programmierung ausgerechnet Javascript-Beispiele gehören, halte ich für fragwürdig. Überhaupt haben Objekte in Javascript nur deswegen eine Bedeutung, weil man ohne Kenntnis darüber die ganze Syntax nicht versteht. (document.images[3].src, z.B.). Derlei hat aber mit dem Generieren von Objekten (geschweige denn von Klassen) nix zu tun. Man kann zwar in Javascript auch Objekte bauen, weil's halt Java zum Vorbild hatte. Aber verwenden tut doch kaum jemand dieses Feature.

Daher: irrelevant und raus damit.--Asw-hamburg 04:26, 2. Nov 2005 (CET)

Jaja. OOP mit dem Prototypen-Konzept ist eine herausragende Eigenschaft von Javascript. Wenn das nicht beschrieben werden soll, dann frage ich mich, was überhaupt noch an Javascript programmiertechnisch eigenartig ist. Alles andere habe ich schon geschrieben. Falls du einmal JavaScripte gesehen hast, die über eine gewisse Komplexität hinausgehen, findest du immer das Erzeugen eigener Objekte. »Kaum jemand nutzt es« ist ein Nullargument. -- 83.129.36.29 20:11, 3. Nov 2005 (CET)

kann ich nicht zustimmen. zuerst: javascript hat java nicht zum vorbild. es hat die gleichen schlüsselwörter, und irgendein marketingfuzzi hat mal beschlossen es sollte so heißen, aber die sprache an sich ist völlig anders. für jemanden der mit C++ oder java großgeworden ist das schwer zu verstehen, daß man einfach keine klassen braucht um OO zu bekommen. es reicht objekte in den rang von prototypen zu erheben.

auch was die vereinheitlichung von funktion und objekt angeht ist JS einfach ein gutes stück weiter. diese vereinheitlichung und auch die einbeziehung von konzepten aus der funktionalen programmierung ist etwas, was JS schon ewig hat, während erst die nachfolger von java und C# wie zum beispiel Xen, Scala (Programmiersprache) oder Boo in dieser hinsicht langsam gleichziehen.

natürlich, javascript hat kein statisches typing - das war als JS geschaffen wurde für eine derart dynamische sprache einfach nicht möglich. man musste, wenn man darauf nicht verzichten wollte, eben eine sprache wie java bauen, die näher an der maschine und weniger abstrakt ist. das einzige wo C++ wirklich deutlich weiter ist, ist generische programmierung.

wenn's dich übrigends böckt, es reichen wenige handvoll zeilen um klassen nachzubauen - nur will das eigentlich niemand, weil es nicht viel bringt. -- -- ∂ 20:54, 3. Nov 2005 (CET) heute mal weeeit aus dem fenster gelehnt

Ich würde ja die Kritik einsehen, dass der Abschnitt an sich deplatziert ist (siehe oben), aber die jetzige Umsetzung halte ich für in sich stimmig. Man kann einen solchen Zusammenhang, wenn man ihn denn beschreibt, nicht völlig ohne Erläuterung des Kontextes beschreiben. Und der allgemeine OOP-Artikel schildert den Kontext m.M.n. nicht ausreichend. -- molily 05:16, 15. Sep 2005 (CEST)

Dann muss der geändert werden. Wenn der Artikel schon das bißchen OOP von Javascript nicht erhellt...--Asw-hamburg 04:26, 2. Nov 2005 (CET)

Ich finde, das könnte auf die Wikibooks ausgelagert werden. -- Benutzer:213.39.223.91

Gute Idee. Allerdings schreibe ich persönlich schon an einem Buch über JavaScript, nämlich an SELFHTML. Daher möchte und kann ich nicht gleichzeitig am JavaScript-Wikibook arbeiten. Vor allem müsste man dort bei Null anfangen. Mitarbeiter gibts auch noch keine (fast genau wie hier). Darauf habe ich nicht einmal Lust. Wer mag sich dessen annehmen? -- molily 05:43, 20. Sep 2005 (CEST)

Mir scheints eher das man den Artikel eher zu einer kleinen Scriptsammlung gemacht hat statt nur wichtige Eigenschaften der Sprache zu beschreiben. -- Crossroad 18:11, 20. Okt 2005 (CEST)

Aus der Wikipedia:Qualitätssicherung/2. November 2005

• Wichtige Unterkapitel fehlen, statt dessen neun überflüssige Unterkapitel
• keine Allgemeinverständlichkeit
• fachliche Mängel (z.B.: Javascript als Beispiel für OOP

Was ist daran falsch? JavaScript IST eine objektorientierte Sprache, lediglich (wie schon weiter oben erwähnt) wird das eher unpopuläre System der Prototypen-Vererbung und nicht die Klassen-Vererbung angewendet. Dubaut 13:39, 7. Mär 2006 (CET)

• offenbar keine Akzeptanz

→ Diskussion:JavaScript

--Asw-hamburg 05:19, 2. Nov 2005 (CET)

JavaScript habe nichts mit Java zu tun

Das ist nicht richtig, insofern als Netscape Inc. die Syntax nachträglich und in Kooperation mit Sun an Java angepaßt hat; gleiche Schreibungen (Syntax) sind also weder ein Zufall noch einfach nur eine Folge davon, daß beide Sprachen sich am an Schreib-Stil von C orientiert haben; sondern Netscape hat ganz bewußt die Syntax von JavaScript der von Java angeglichen.

Meines Wissens existierte die Sprache schon vor dem Deal mit Sun unter dem Namen LiveScript. Es gab eine nachträgliche Anpassung der Syntax? Hast du dazu Quellen? Mir ist dazu nichts bekannt. Meines Wissens änderte sich zwischen LiveScript und JavaScript lediglich der Name (bzw. es änderte sich einiges von Netscape 2 zu Netscape 3, aber keine Sprachgrundlagen im Sinne einer »Anpassung an Java«). Ich lasse mich aber gerne vom Gegenteil überzeugen, wenn du Quellen nennst. -- molily 13:22, 23. Mär 2006 (CET)

Es ist richtig, daß die Sprache schon vor der Kooperation mit Sun existierte, man kann natürlich auch nur etwas an etwas anderes anpassen, wenn es schon vor der Anpassung existiert.

Dass ich die Quelle der Information aufzufinden, jetzt Zeit aufwenden werde, halte ich eher für unwahrscheinlich, da dies extrem aufwendig wäre, weil ich 1. nicht nur ein Buch oder nur 4 Web-Seiten über JavaScript gelesen habe und weil ich 2. solche Texte normalerweise nicht mit der Absicht lese, Beweise zu sammeln, um diese anderen Lesern vorzulegen. Benutzer:Parzi Irgendwann im Kosmos irgendwann danach.

Trotzdem bleibt JavaScript eine Erfindung von Netscape und auch die Idee, den Namen JavaScipt zu verwenden, geht meines Wissens auf Netscape zurück. Dass JavaScript eine eingetragen Marke von Sun Microsystems sein soll, wie der Artikel behauptet, erscheint mir daher äußerst fragwürdig.

Überarbeitet

Ich habe mal das ganze Handbuch zu JS rausgeschmissen; das gehört in Wikibooks rein, aber nicht in eine Enzyklopädie. Ich habe auch noch jede Menge anderes Zeug rausgejagt, das einfach nicht in den Artikel gehört.HD - B - @ 11:02, 30. Apr 2006 (CEST)

Der Hinweis dass der Artikel lang ist, ist durchaus berechtigt. Es ist aber sicher keine Lösung des Problems einseitig aktiv zu werden und erst mal einfach zu löschen und zu warten, dass andere den Inhalt in das Wikibook verschieben. Deshalb erst mal ein 'Revert' HJH 22:47, 30. Apr 2006 (CEST)

Das meiste steht bereits im Wikibook. Ich werde die bereits migrierten Inhalte hier löschen. -- molily 00:01, 1. Mai 2006 (CEST)

Kann jetzt eigentlich langsam mal der Überarbeiten-Baustein raus? --jpp ?! 13:13, 10. Mai 2006 (CEST)

Ich bräuchte mal Hilfe

Guten Tag, allerseits! Ich hab ein Problem, aber ich frage mich grade, ob hier die richtige Adresse ist. Ich benötige nämlich eine Funktion in JavaScript oder zu Mindest eine Internetseite, von der ich die holen könnte. Aber ich hab jetzt die Diskusion hier verfolgt und bin zu dem Schluss gekommen, dass Wiki nun mal eine Enzyklopädie und kein Fachhandbuch ist. Dennoch möchte ich hier mein Problam erläutern, weil ich voller Zuversicht bin, dass dies hier Fachleute lesen, die mir bestimmt helfen können.

Also folgendes: Ich hab von der Schule im Informatikunterrich die Aufgabe bekommen ein Programm mit html und JavaScript zu schreiben. Ich bin schon ziemlich weit gekommen, aber nun brauch ich einen festgelegten Befehl, der folgendes bewirkt: Der Nutzer des Programmes hat ein Wort eingegeben. Nun soll der Computer das Wort in einem zweiten Fenster wiedergeben, aber vorher die letzten drei Buchstaben des Wortes gelöscht haben. Weiß jemand wie der Befehl, die letzten 3 Buchstaben zu löschen, heißt? Ich hab leider kein Benutzerkonto auf Wiki. Drum müsste man mir die Antwort hier drunter schreiben. Sorry, dass ich jetzt noch mehr Platz beanspruche ...

-- Orpheus ex umbra 17:06 7.Mai.2006

moin, kuck dir die methoden des String-prototypen mal genau durch, und du wirst die lösung finden. mehr will ich jetzt nicht schreiben, schließlich ist es deine hausaufgabe. -- ∂ 17:18, 7. Mai 2006 (CEST)

Tausend Dank! Ich hab's gefunden! -- Orpheus ex umbra 14:26 10.Mai 2006

Was mit JavaScript nicht funktioniert

Im Artikel heißt es folgende Dinge seien mit JavaScript nicht möglich:

1. wirksamer Passwortschutz, da das Passwort in Klartext im Quelltext der Seite stehen würde oder zumindest der Verschlüsselungscode, so dass es rekonstruiert werden kann
2. Auslesen der IP-Adresse oder des Internetproviders

Punkt 1 halte ich nicht für korrekt, da folgendes Vorgehen durchaus sinnvoll sein könnte. Persönliche Daten sind auf dem Server etwa einer MySQL-Datenbank gespeichert. Diese Daten sollen an den Benutzer sicher übertragen werden. Ein Serverprogramm etwa in PHP programmiert, könnte die Daten verschlüsselt, z.B. als Textvariablen innerhalb von generiertem JavaScript, übertragen. Der Benutzer könnte in ein Formular (<input type=password ...>) den geheimen Schlüssel eintragen. Eine JavaScript-Funktion könnte die Daten dann entschlüsseln und darstellen. Die Eingaben, insbesondere das Passwort zur Entschlüsselung, brauchen nicht übertragen werden.

Welchen Sinn Punkt 2 ergeben sollte, scheint mir rätselhaft. Benutzer:Fsswsb 30.05.06

Mit einem Formular und CGI geht es natürlich, es geht um einen rein JS-basierten Passwortschutz. Bei 2 gibt es das rein technische Problem, dass ein Rechner mehrere IP-Adressen hat (u.a. 127.0.0.1) und der Browser und damit das JS nicht so ohne weiteres erkennen kann, welche die nach außen sichtbare ist, von Proxies usw. gar nicht zu reden.--Gunther 19:19, 30. Mai 2006 (CEST)

Wenn ich das jetzt richtig verstehe geht es um die Internetadresse des Clients (REMOTE_ADDR). Diese kann auf dem Server ausgelesen werden. Der kann Server damit erkennen von welchem Rechner bzw. Client Daten übertragen wurden. Ich kann aber nicht recht nachvollziehen warum es von Interesse sein sollte diese in JS auszulesen. Folglich sehe ich es nicht als Nachteil, dass dies nicht möglich ist.

(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 20:16, 30. Mai 2006)

Ja und?--Gunther 20:19, 30. Mai 2006 (CEST)

Zu 1: Wenn der Angreifer nicht mithören kann, ein Directory Listing und Spiders nicht erlaubt sind, und einige andere Voraussetzungen erfüllt sind, die mir gerade nicht einfallen, könnte dann etwas wie

 pwd = "password"; // aus Formular auslesen
 hash = hashfct(pwd);
 this.location.href = hash + ".htm";

einen gewissen (wenn auch schwachen) Schutz liefern? Horrorist 21:39, 30. Mai 2006 (CEST)

Die Hashfunktion kannst Du Dir sparen, das ist in jedem Fall security by obscurity.--Gunther 21:54, 30. Mai 2006 (CEST)

Ja, genau. Ich wollte damit auch nur sagen, dass ein "reiner" JS-Passwortschutz möglich ist, ohne dass das Passwort im Quelltext steht bzw. daraus rekonstruiert werden kann. Ob der noch "wirksam" ist, möchte ich nicht beurteilen. Die Hashfunktion kann unter Umständen auch Vorteile haben... Horrorist 00:20, 31. Mai 2006 (CEST)

Ich halte die ganze obige Diskussion und auch Teile des Artikels für überflüssig. Es werden hier immer zwei Sachen miteinander vermischt: clientseitige Programmierung und JavaScript. Dabei werden Argumente beliebig von einem auf das andere Thema übertragen. Z.B. Passwortschutz. Dieser ist in vernünftiger Weise selbstverständlich nicht innerhalb eines autonomen Programms möglich. Das ist jedoch keine Eigenschaft von JavaScript. --Squizzz 00:30, 31. Mai 2006 (CEST)

Warum "Überarbeiten"?

Das Bapperl ist deswegen drin, weil die Wikipedia eine Enzyklopädie ist (bzw. werden soll), dieser Artikel aber nicht im enzyklopädischem Stil geschrieben ist. Besonders deutlich:

• Das Mini-Tutorial muss raus
• Die alberne Liste mit Ratschlägen "gutes/böses JavaScript" muss raus

HD hatte dankenswerterweise bereits im April aufgeräumt, aber anscheinend können einige selbstverliebte Mitarbeiter nicht vertragen, dass Ihr Text unter den Tisch fallen soll. Schade.

Pjacobi 00:03, 31. Mai 2006 (CEST)

Fachartikel einleiten

Ich meine, dass eine Einleitung dem Laien eine Vorstellung von der Sache geben und nur allgemein verständliche Begriffe verwenden soll. Fachtermini hingegen gehören in den Teil nach der Einleitung. Das halte ich für die Methode der Wahl, abschreckungsfrei zu schreiben. Vorteil: Möglichst Viele profitieren, und mancher Laie fühlt sich ermuntert, weiter zu lesen. Können wir uns darauf verständigen, dass eine Einleitung diese Funktion haben soll?

Wenn wir darin d'accord gehen, stehen die Begriffe, die während der letzten zwei Tage in die Einleitung gelangt sind, diesem Ziel entgegen. Der interessierte Laie steigt aus, wenn er von diesen Termini begrüßt wird: "Elemente", "Hyperlinks", "Formularfelder", "Attribute", "Funktionen", "Ereignisse", "Events", "Anweisung" "<input onclick="dosomething()""

Laien sind in meinen Augen weder HTML-Programmierer noch die Computer-Versteher meines Freundeskreises, sondern z. B. Klempner, Ärzte, Schriftsteller oder sehr junge Menschen, die noch erkunden wollen, ob eine Sache ihres Interesses wert ist.

Wollen wir diese Leute nicht aussperren, sondern als Leser gewinnen, gehören Fachbegriffe in den Teil nach der Einleitung. Diese Trennschärfe und das Augenmaß für den zumutbaren Stil sind wir den Lesern schuldig.

Ich bin dafür, dass die Autoren der genannten schwer verdaulichen Termini sie in den Teil nach der Inhaltsübersicht verlegen, dort sachgemäß einfühen und die Einleitung so bekömmlich wie möglich gestalten.

"Den Stil verbessern, das heißt den Gedanken verbessern." Nietzsche

Mit besten Grüßen

--IZazen 14:15, 31. Mai 2006 (CEST)

In der aktuellen Einleitung steht, dass JavaScript bei ASPs verwendet wird. Meines Wissens kommt dort jedoch JScript zum Einsatz. Generell scheinen mir im Artikel die Begriffe JavaScript, ECMA262 und JScript teilweise synonym verwendet zu werden. --Squizzz 18:38, 31. Mai 2006 (CEST)

JavaScript und JScript sind (mehr oder weniger konforme) Implementationen des Standards ECMAScript. Dieser Artikel behandelt alles zusammen. --Pjacobi 19:51, 31. Mai 2006 (CEST)

Dann muss aber noch extrem viel getan werden, denn momentan behandelt der Artikel nicht alles zusammen bei Wahrung der Unterschiede. ECMAScript hat den konkreten JavaScript-Anwendungsbereichen und -Funktionen erst einmal nichts zu tun, auf die der Artikel ausgerichtet ist. -- molily 16:08, 1. Jun 2006 (CEST)

Ganz mein Reden, der Artikel ist in vielen Teilen falsch ausgerichtet. Zum Anwendungsbereich Webclient-Programmierung ist ja auch zu bemerken, dass der Artikel Document Object Model nicht gerade überfüllt ist. --Pjacobi 16:24, 1. Jun 2006 (CEST)

ECMAScript

Natürlich handelt der Artikel von ECMAScript, nicht nur weil der REDIRECT hierherzeigt, sondern hauptsächlich weil JavaScript eine Implementation des Sprachstandards ECMAScript ist. Nur ganz wenige, noch zu überarbeitende Teile des Artikels, sind JavaScript-spezifisch, insbesondere der Abschnitt "Geschichte". --Pjacobi 17:44, 8. Jun 2006 (CEST)

elseif

In JavaScript gibt es im Gegensatz zu anderen Programmiersprachen keine Kontrollstruktur

if ... elseif .... Stattdessen kann man zwei If-Anweisungen verwenden, von denen die
erste die zweite als Else-Code aufnimmt:

steht im widerspruch zu

Beliebig viele "Else if"-Blöcke sind erlaubt:

ist ein "elseif" so wie im codebeispiel auf der artikelseite angegeben nun möglich:

if (Bedingung) {
    Anweisungen;
} else if (Bedingung) {
   Anweisungen;
} else if (Bedingung) {
   Anweisungen;
} else {
   Anweisungen;
}

oder nur über den trick:

if (Bedingung) {
    Anweisungen;
} else {
    if (Bedingung) {
        Anweisungen;
    } else {
        Anweisungen;
    }
}

?

Gary Luck Diskussion 15:25, 21. Jun 2006 (CEST)

Ein „elsif“ ist nich möglich, ein „else if“ jedoch schon. Der Unterschied liegt darin, dass „elsif“ ein eigenes Wort wäre das für sich allein vom Parser erkannt wird. Bei „else if“ ist das nicht der Fall. Dies ist nur eine Kurzschreibweise für „else { if ...}“. Der Unterschied ist für den Programmierer in der Regel jedoch unwichtig. --Squizzz 18:54, 21. Jun 2006 (CEST)

--> "Inkrementier-Ausdruck" erklären und/oder Verlinken! Konnte als Schüler zunächst nichts mit anfangen!

Unausgewogenheit Sprachdefinition<->Laufzeitsystem?

Also, wenn der Artikel so ausführlich auf die Sprachdefinition und die Eigenschaften des Objektsystems eingeht (was ich nicht schlecht finde, auch wenn man es vielleicht "lexikographischer" machen könnte), dann sollte auch zumindest kurz die Einbindung der üblichen JavaScript-Implementierungen in die Browser besprochen werden. Das "window"-Objekt beispielsweise taucht am Ende so "en passant" auf, ohne dass es vorher mal erwähnt wurde. Man sollte also zumindest kurz sagen, dass die JavaScript-Runtime auf bestimmte Weise die "aktuelle Seite" und den Browser im Objektgraphen abbildet, man sollte die wichtigsten vordefinierten Objekte nennen etc. Im Moment hängt die ausführliche Erklärung der Sprache selbst etwas zusammenhanglos in der Luft.

Multi io 21:46, 1. Sep 2006 (CEST)

Missbrauch

Seine Webseite vor Datenraub zu schützen ist wohl kein Missbrauch einer Scriptingsprache. Desweiternen gibt es doch sicher ernsthafte Missbrauchszenarien. Wie auch schon gebracht, siehe Popups. Ich bin der meinung dieser Teil sollte auf neutraliät geprüft werden und generell werweitert bzw. überarbeitet werden.

Eddy 13:35, 7. Sep 2006 (CEST)

Da man Inhalte auf Webservern so nicht vor "Raub" schützen kann, ist der Einsatz dazu sinnlos. Ob es Missbrauch ist oder ein Mittel sich lächerlich zu machen ist Ansichtssache.

Wenn du Angst hast, dass es dir gestohlen wird, dann veröffentliche es halt auch nicht. --ChristianErtl 18:09, 19. Mai 2007 (CEST)

Was aber rein sollte: Fast alle Würmer, Trojanische Pferde und sonstige Schädlinge brauchen JavaScript oder ähnliches, um wirksam zu werden. Somit ist Javascript-Abschalten auch ein Sicherheitsgewinn (unter Verlust von Komfort). --217.91.18.104 11:07, 19. Dez. 2006 (CET)

Naja, Firefoxnutzer haben es da gut! Wer die Erweiterung NoScript nutzt, kann selber entscheiden welche Seiten Scripte ausführen, alle anderen werden unterdrückt. --MfG, Bkmzde 08:33, 30. Jan. 2007 (CET)

Ich schreibe gerade eine Studienarbeit in welcher ich die unter Missbrauch genannten Punkte aufgreifen möchte. Ich finde die Überschrift jedoch auch nicht allzu passend / neutral genug. Als Bsp. wäre z. B. die Reduzierung des Traffics zu nennen, die durch eine Verschleierung von Grafiken entsteht. Klar ist es für den Benutzer auf den ersten Blick nur ärgerlich, jedoch muss man es auch wirtschaftlich sehen, da die Kosten für den erhöhten Traffic bei einer großen Webseite letztendlich mit großer Wahrscheinlichkeit wieder beim Benutzer landen. Leute die bisschen Ahnung haben kommen natürlich trotzdem an die Links, aber die Verschleierung ergibt meines Erachtens trotzdem Sinn. Mein Vorschlag: Übreschrift "Missbrauch" entfernen und einfach mit etwas in der Art weitermachen: "Außerdem wird die Skriptsprache oftmals dafür verwendet um die Interessen des Betreibers einer Webseite durchzusetzen. Diese Verwendung wird vom Benutzer oftmals als störend empfunden. Dazu gehören folgende Anwendungsgebiete:" Gruß --Knowledgeisnotwisdom 20:37, 5. Jun. 2008 (CEST)

im Artikel finde ich nichts, was deiner Beschreibung entspricht. Zum Thema Grafiken im Abschnitt Missbrauch steht da nur was zum Kontextmenü. Solltest du das meinen verstehe ich nicht, was das für eine Trafficeinsparung ergeben soll.--Fritzbruno 16:29, 6. Jun. 2008 (CEST)

Nun ja, wenn der Benutzer auf das Kontextmenü über einer Grafik zugreifen kann, dann gibts dort den Punkt "Grafikadresse kopieren" bzw. "Grafik anzeigen" und dann is die Adresse in der Adressleiste des Browsers zu sehen. Und nehmen wir mal an es ist ein "brisantes Bild" und der Link wird z.B. im IRC gepostet, dann kommen sehr schnell paar GB / TB Traffic zustande... Mit etwas KnowHow kriegt man natürlich trotzdem leicht den Link raus, aber man muss halt wissen wie und das weiß nicht jeder Hans Wurst. ich würde es einfach neutraler und sachlicher finden, wenn man "missbrauch" entfernt und einfach schreibt: "Außerdem wird die Skriptsprache dafür verwendet um die Interessen des Betreibers einer Website durchzusetzen. Diese Verwendung wird vom Benutzer oftmals als störend empfunden und wird als „schlechter Stil“ angesehen. Dazu gehören folgende Anwendungsgebiete:" - sag mir was dagegen spricht? MfG

Achso und das man sich mit javascript schadcode einfangen kann fehlt mir irgendwie auch, da geb ich meinem vorredner recht... --Knowledgeisnotwisdom 20:39, 6. Jun. 2008 (CEST)

Eine Webseite ist im Allgemeinen immer dazu da, die Interessen des Betreibers durchzusetzen. Wenn diese darin bestehen, die Browserfunktionalität des Besuchers mit JavaScript zu stören, kann man das sehr gut als Missbrauch bezeichnen. Schadcode kann man sich dagegen mit JavaScript nicht einfangen. Es ist zwar so, dass sich viele Browserlücken mittels JavaScript ausnutzen lassen, das ist aber kein Problem von JavaScript an sich. -- net 00:53, 7. Jun. 2008 (CEST)

Stimmt auch wieder. Naja gibt wohl auch wichtigere Themen, dann lassen wir das ma so (obwohl das mit dem traffic ein gutes argument ist, dass der punkt mit den links nicht immer als missbrauch zu gelten ist, sondern eher ein schutz sein kann...) naja whatever --Knowledgeisnotwisdom 01:22, 7. Jun. 2008 (CEST)

ich muss nur noch mal auf deinem Grafikbeispiel rumreiten: Für derlei Probleme gibt es sinnvollere Lösungen, zB serverseitige Techniken, die das Bild nur vom Server ausliefern lassen, wenn es von einer eigenen Seite angefordert wird. Da die Manipulation am Browser also nicht mal nötig, geschweige denn irgendwie effektiv ist, finde ich die Bezeichnung "Missbrauch" sehr treffend.--Fritzbruno 07:02, 7. Jun. 2008 (CEST)

Liste von objektorientierten Programmiersprachen

http://de.wikipedia.org/wiki/Liste_von_objektorientierten_Programmiersprachen Hier steht noch immer JavaSkript in der Liste, ich erwähne das mal hier.

Im Artikel wird im ersten Link "OB" noch immer nach "OO" verlinkt. Ich möchte den Erstellern des wikis nicht reinmurksen, daher ändere ich das nicht selbst. (nicht signierter Beitrag von 84.140.37.94 (Diskussion | Beiträge) 09:35, 21. Apr. 2006 (CEST))

Neue Einleitung

Ich hab die Einleitung etwas überarbeitet. Alles in allem ist der Artikel eigentlich eine Symbiose aus DOM 0 und JavaScript. Vielleicht sollte man beides trennen? Die Sprache hat sich mittlerweile schon lange von den Browsern losgelöst... Cookies/HTML/alert etc. sind alles nicht Teil von JavaScript (siehe z.B. VBS im IE oder die Beispiele mit Tcl vom W3C in der HTML Spec) sondern vom Browser. --Volatile 12:40, 19. Apr. 2007 (CEST)

Client- oder Serverseitig?

Der Artikel widerspricht sich. In der Einleitung steht (hab's mal stehen lassen): "Es gibt daneben in JavaScript geschriebene Programme, die serverseitig ausgeführt werden. Der HTML-Code wird also serverseitig erstellt und an den Webbrowser geliefert." Im "Überblick" heißt es dagegen: "JavaScript ist eine objektbasierte Skriptsprache, die im Unterschied zu serverseitigen Skriptsprachen wie zum Beispiel Perl oder PHP, clientseitig eingesetzt wird" Was denn nun? Meines Wissens gibt es kein serverseitiges JavaScript. Falls doch, hat jemand ein Beispiel dafür? --Kjuu 15:42, 18. Apr. 2007 (CEST)

Doch es hat sich nur nicht durchgesetzt, Netscape hatte immer auch Serverprodukte im Angebot! --Popolfi 18:41, 6. Apr. 2008 (CEST)(nachträgliche Signatur)

Es gibt einige Verwendung für JavaScript außerhalb des Web-Browser und außerhalb von Web-Applikationen im Allgemeinen. JavaScript wird beispielsweise - oft aber in angepasster oder erweiterter Form - gerne für Anwender-Scripte in Applikationen genutzt. Es gibt aber auch komplette Server-seitige Web-Frameworks, zum Beispiel eine Ruby on Rails Portierung. Die kommende Version 3.0 des Spring Frameworks wird eine Server-seitige JavaScript-Integration enthalten. Manchmal kommt die Sprache auch für DSLs zum Einsatz oder um einfach Tests schreiben zu können. Allerdings hat sie sich außerhalb des Browser bisher wirklich kaum durchgesetzt.

Ansichtssache, VBScript und JScript sind eng verwandt und laufen auf dem gleichen Windows Scripting Host. Wo also VBS läuft kann auch JScript laufen! --Popolfi 18:44, 6. Apr. 2008 (CEST)

---

JScript und JavaScript nicht kompatibel??

Der Sprachkern von JScript ist haargenau JavaScript, incl. diverser als Designfehler angesehener Dinge, bei denen MS darauf bestand, sie drinzulassen. Dass die DOM-Bibliotheken an einigen Stellen anders sind, hat damit nix zu tun. MS hat mit JScript auch keine "eigene" Sprache entwickelt, sondern die Netscape-Implementation nachgebaut, und zwar sehr sorgfältig. Und dass das ganze den Browser-Krieg auslöste, halte ich auch für eine recht zweifelhafte Behauptung. Ich wäre dafür, diesen Absatz zu ändern. Multi io 06:32, 16. Feb. 2007 (CET)

"Beide Sprachen sind nicht kompatibel zueinander, allerdings sind sie sich ähnlich" irgendwie ziemlich ungeschickt formuliert dieser Satz, weil wenn jetzt jemand wenig/keinerlei Ahnung von JScript hat und danach im Wiki sucht landet er wieder auf der Javascriptseite ohne irgendwelche zusätzlichen Infos über JScript. (Weder in den Links, noch generell irgendwelche Infos über JScript, zu Javascript findet man aber Links zu Mozilla...) --Lastwebpage 00:40, 31. Mär. 2007 (CEST)

wikibooks

ist ja schon sehr viel, vieleich ein wikibook?

Ich finde es nicht wirklich angebracht, fast schon so etwas wie ein kleines Tutorial oder eine Sprachreferenz in einen Artikel einzubauen. Daher denke ich, man sollte diese Inhalte in ein Wikibook verschieben. --84.175.111.148 13:54, 31. Mär. 2007 (CEST)

öffentlich und privat

Ich weiß es einfach nicht ob das wirklich so richtig ist, das sollte mal jemand nachlesen ob das wirklich so stimmt:

Funkionen,Elemente innerhalb der Funktion

privat

Funkionen,Elemente innerhalb der Funktion mit einem Verweis auf die aktuelle Instanz (this)

öffentlich

Das mag ja durchaus stimmen, nur wiederspricht das irgendwie dem was die meisten anderen Programmiersprachen unter öffentlich und privat verstehen. --Lastwebpage 00:52, 31. Mär. 2007 (CEST)

IMHO sollte man hier unbedingt statt "privat" eher "lokal" benutzen und statt "öffentlich", "Methode" oder "Instanz-Variable". Die Begriffe "privat" und "öffentlich" werden sonst sehr leicht mit den Schlüsselwörtern "private" und "public" verwechselt. Wenn man es genau nimmt ist der Abschnitt "Öffentliche und private Methoden und Eigenschaften" überflüssig und irreführend. (nicht signierter Beitrag von 87.187.228.41 (Diskussion) 13:08, 29. Mai 2007)

Ich bin kein OOP-Fachmensch, aber inwiefern widerspricht diese Einteilung der in der OOP üblichen (siehe Datenkapselung (Programmierung))? In JavaScript gibts zwar keine Klassen, sondern nur Instanzen, die durch Konstruktoren erzeugt werden, aber wieso funktioniert dort die Unterscheidung private - public nicht? -- molily 21:19, 29. Jun. 2007 (CEST)

Java & SUN

Java ist eine Marke von SUN aber doch nicht JavaScript!!!!

Da Netscape ja auf die Marke Java bei der Benennung zurückgegriffen hat, ist sicherlich auch JavaScript eine Marke von Sun. --ChristianErtl 14:50, 23. Jun. 2007 (CEST)

Siehe hier: http://www.sun.com/suntrademarks/#J --ChristianErtl 14:57, 23. Jun. 2007 (CEST)

Ergänzung zu Vererbung unnötig

Der Text nach dem Satz »Ein weiteres Beispiel zum Verständnis der Vererbung:« im Abschnitt »Vererbung« sagt nichts neues und erklärt die Vererbung auch nicht nochmal verständlicher. Er stellt lediglich fest, dass wenn man einem abgeleiteten Prototyp (PKW) eine Methode gibt, die nicht bei Instanzen eines anderen abgeleiteten Prototyps (Motorrad) existiert. Ach was. Als »Lösung« wird zunächst das doppelte Notieren, dann das bessere Notieren beim Ursprungsprototyp (Kraftfahrzeug) vorgestellt. Ist ja auch alles richtig, aber gehört das dort wirklich hin? Dass dem PKW-Prototyp eine Methode angehängt wird, hat sowieso nur exemplarische Gründe. Logisch gesehen würde man wahrscheinlich allen Kraftfahrzeugen eine Eigenschaft Radanzahl und Methode zeigeRadanzahl geben - die sind natürlich nicht eigentümlich für PKWs. Wenn sich einer daran stört, bitte das ursprüngliche Beispiel mit PKW.prototype.Radanzahl und PKW.prototype.zeigeRadanzahl ändern. Die Ergänzung werde ich daher herausnehmen. -- molily 21:45, 29. Jun. 2007 (CEST)

Alles hat ein Ende !

Ich habe mir diesen Artikel nun mehrfach durchgelesen und dachte zunächst ich könnte durch einige kleine Änderungen etwas zu seiner Qualität beitragen. Nach reiflicher Überlegung bin ich zu dem Schluß gekommen : "Irgendwo ist da Hopfen und Malz verloren". Nochmehr nachdem ich mir die Diskussionsbeiträge angeschaut habe. Da hat nichts Hand und Fuß. Der Artikel schweift aus in Allgemeinpläze wie 'Skriptsprache'; 'objektorientiert',.... dann geht die Diskussion in die Richtung ob denn nun oder nicht. Meinen Beitrag dazu möchte ich dann doch einigen ersparen, so ich eine sinnvolle eher darin sehen würde ob denn nun Javascript überhaupt als Programmiersprache bezeichnet werden kann. Jedenfalls wird im Artikel auf syntaktische Details eingegangen, die meines Erachtens hier nichts zu suchen haben (auch aufgrund der etwas redundanten Linkliste), während auf relevante Dinge wie beispielsweise der Verfügbarkeit (Existenz ?) von Interpretern die nicht in Browser eingebettet sind oder tatsächlich vorhandenen Entwicklungumgebungen überhaupt nicht eingegangen wird.

Ich bitte alle Beteiligten sich zu überlegen ob es nicht am sinnvollsten sein könnte den Artikel vollständig zu löschen und komplett neu aufzubauen !

samtrot

PS: Babel kennt keinen Hopfen

*seufz* das hab ich mir auch schon hin und wieder gedacht, und an neuschreiben. warum javascript allerdings keine programmiersprache sein sollte, müsstest du mir erklären. -- ∂ 10:46, 6. Jul. 2007 (CEST)

Wenn dir der Artikel zu wenig Inhalt bietet, warum nimmst du dann vorhandene Informationen wie „JavaScript ist eine objektbasierte Programmiersprache“ oder „Bei JavaScript interpretiert ein Interpreter einer Script-Engine zuvor aus Quelltext (JIT-)compilierten Bytecode“ raus? Deine heutigen Änderungen haben IMO den Artikel jedenfalls nicht besser gemacht. Miste doch lieber den Absatz Sprachelemente aus. Die syntaktischen Ausschweifungen haben in dem Artikeln nämlich wirklich nichts verloren.

BTW: Bitte signiere deine Beiträge hier in der Diskussion. -- net 12:04, 6. Jul. 2007 (CEST)

die geschichte mit dem interpreter ist so nicht richtig: mag sein, daß eine JS-engine das so macht, es gibt aber diverse andere möglichkeiten und die spec macht da keinerlei vorschriften. -- ∂ 12:54, 6. Jul. 2007 (CEST)

Der Text ging ja auch mit „oder (seltener) den Quelltext direkt.“ weiter und war schon richtig. -- net 13:21, 6. Jul. 2007 (CEST)

nein. direkt auf dem quelltext wäre zwar möglich, aber ich bin mir ziemlich sicher, daß das niemand freiwillig versucht. wohl eher operiert die engine auf dem AST. aber selbst wenn sie maschinencode erzeugte, wäre das eine eigenschaft der engine, und nicht der sprache! -- ∂ 16:13, 9. Jul. 2007 (CEST)

Benutzerfreundlichkeit?

Inwiefern ist eine Website nicht benutzerfreundlich nur weil sie JavaScript voraussetzt? Vielleicht ist es bekannt das selbst die Vorgaben des W3C inzwischen JavaScript umfassen. Wer sich vor Angriffen via JavaScript schützen will sollte entsprechend vorsorgen. Bei Firefox hilft dabei z. B. die Erweiterung NoScript hervorragend. --Sturmkind 08:34, 21. Jul. 2007 (CEST)

Ähm, sie benachteiligt Browser und Zugangssysteme, die kein JavaScript unterstützen. -- molily 22:28, 30. Sep. 2007 (CEST)

Deswegen findet man auch noch so oft Heu an Tankstellen um der großen Anzahl reitender Bürger gerecht zu werden. Mal ehrlich welcher Browser mit Verbreitung kann kein Javascript. --83.171.156.78

Hilfe

Wisst ihr, wo man das JavaScript downloaden kann? Denn im Google hab ich nichts gefunden.--Frogger14 11:37, 16. Aug. 2007 (CEST)

einen JS-interpreter? ein bestimmtes, in JS geschriebenes skript? -- ∂ 11:44, 16. Aug. 2007 (CEST)

Was ist NJS

...obwohl auch eigenständige Anwendungen mit anderen Interpretern wie NJS möglich sind.

Entweder muss es heißen ...obwohl auch eigenständige Anwendungen mit anderen Interpretern als NJS möglich sind.oder ...obwohl auch eigenständige Anwendungen mit anderen Interpretern, wie NJS, möglich sind. In beiden Fällen stellt sich die Frage, was NJS ist. Weder Kiki noch Google kenne dieses Kürzel. Man sollte das imho entweder erklären oder löschen.--91.7.115.42 20:13, 23. Okt. 2007 (CEST)

http://www.njs-javascript.org/ -- ∂ 21:03, 23. Okt. 2007 (CEST)

Wer entwickelt JS offiziell weiter? In den Artikel?

Tag, wer entwickelt JavaScript nun eigentlich offiziell weiter und definiert Standards? Ich kann leider keinerlei eindeutige Informationen entdecken. Nach der Praxis hat Mozilla die Entwicklung übernommen aber inwieweit ist das offiziell und inwieweit definiert Mozilla die Standards die dann alle anderen Browser ebenfalls umsetzen? --Rudi 16:33, 21. Dez. 2007 (CET)

Niemand. Mozilla entwickelt proprietäre Zusätze für den Kern und nennt die »JavaScript Versionsnummer« (bisher 1.6, 1.7, 1.8). Andere Browser haben diese Erweiterungen soweit ich weiß nocht nicht oder nur sehr punktuell übernommen. Eine Weiterentwicklung von ECMAScript, also dem eigentlic hmaßgeblichen Standard, findet in der Arbeitsgruppe TC39 von ECMA statt: http://www.ecmascript.org/ Dort wird aber eine ganz neue Sprache entwickelt. -- molily 16:55, 18. Mär. 2008 (CET)

Web-basierte Sprache?

Im Artikel wird Javascript als Web-basierte Sprache bezeichnet bzw. in der Diskussion unten wird sogar vorgeschlagen, sie explizit so zu definieren. Das ist aber nicht korrekt: Zwar wird Javascript hauptsächlich im Web eingesetzt, aber nicht ausschließlich: Z.B. die Adobe CS2-Suite (Photoshop, Indesign) ist scriptfähig, wobei ausser VBscript und Applescript auch Javascript als plattformübergreifende Sprache benutzt werden kann. Das hat nichts mehr mit dem Web zu tun. Das DOM sieht dort auch anders aus, z.B. gibt es kein window-Objekt, sondern statt dessen das Objekt "application" und noch viele andere, die in Javascript für's Web nicht existieren. Totzdem ist es reines Javascript, wird jedenfalls von Adobe so bezeichnet. Jedes andere DOM tut's also prinzipiell auch, daher ist Javascript grundsätzlich unabhängig vom Browser-DOM und somit vom Web, w.z.b.w. Eine auffällige Eigenschaft von Javascript ist z.B. die Tatsache, dass keine System-Aufrufe möglich sind, eine Einschränkung, die z.B. in der die CS2-Suite für VBscript oder AppleScript nicht gilt, wohl aber für JavaScript dort. Habe mal die Einleitung des Artikels entsprechend umgeschrieben. --Kjuu 13:58, 18. Apr. 2007 (CEST)

JavaScript ist der Name für das einst von Netscape gestartete Sprachenprojekt, das ganz klaren Bezug aufs Web hatte. In Nicht-Web-Anwendungen wird insofern - um mal begrifflich scharf zu sein - nicht JavaScript, sondern ganz einfach eine andere ECMAScript-Implementierung verwendet. Dass Adobe den Unterschied begrifflich einebnet, ist marketing-technisch erklärbar, aber technisch Unsinn. JavaScript ist gleich ECMAScript + DOM 0 (»Browser Object Model«) + W3C DOM + Web-spezifische proprietäre Browserfeatures. JavaScript verhält sich zu ECMAScript ungefähr so wie z.B. XHTML zu XML. XML ist der Rahmen, XHTML die konkrete Sprache.

Lange Rede, kurzer Sinn, es ist nicht sonderlich klug, alle ECMAScript-Implementationen als JavaScript zu bezeichnen, sondern eben nur die, die im Web/HTTP/HTML/Browser-Kontext lebt. Leider mischt der Artikel ECMAScript und JavaScript momentan völlig. Z.B. »[JavaScript]wird auch gerne als Skriptsprache für Spiele eingesetzt« - gemeint ist einfach irgendeine ECMAScript-Implementation (und davon gibts tatsächlich viele), nicht JavaScript im genannten Sinne! -- molily 21:31, 29. Jun. 2007 (CEST)

Eben. Es sollte einen Artikel ECMAScript geben, statt eines Redirects hierher. Dort kann dann auch auf die anderen Anwendungszwecke eingegangen werden. -- iGEL·대화·Bew 16:52, 31. Aug. 2007 (CEST)

Dafür. ECMAScript sollte Hauptartikel sein, und JavaScript wirklich nur das behandeln, was JavaScript von ECMAScript abhebt. Spätestens mit Erscheinen von ECMAScript5 (also jetzt) find ich's echt schlecht, keinen eigenen Artikel dazu zu haben. --Fusselwurm 22:32, 8. Dez. 2009 (CET)

Anwendungsbeispiel (JavaScript)

Anwendungsbeispiel: (Quadrat einer Zahl berechnen) funktioniert nur eingeschränkt, die Ausgabe "Bitte gib eine gültige Zahl ein!" erscheint nicht, stattdessen kommt "Das Quadrat von NaN ist NaN!" als Ausgabetext. Offenbar ist hier ein Fehler in "if (Zahl == NaN)", bitte korrigieren! Meine Kenntnisse erstrecken sich nicht auf JavaScript. Dank im Voraus! Timothy da Thy 14:16, 17. Jun. 2008 (CEST)

sollte jetzt funktionieren--Fritzbruno 08:26, 6. Jul. 2008 (CEST)

Ich habe das bisherige Anwendungsbeispiel durch eine typische Anwendung, die - allerdings stark vereinfachte - Validierung einer Formulareingabe, ersetzt. Inhaltlich sind sich die beiden Beispiele ähnlich (Verarbeitung einer Eingabe) aber der praktische Nutzen von JavaScript wird im neuen Beispiel deutlicher.--Fritzbruno 12:48, 7. Jun. 2009 (CEST)

Neues Fass aufmachen: Sprachklassifizierung allgemein und Diskussion der aktuellen Einleitung speziell

Hallo in die Runde,

seit Jahren bin ich nur stiller Beobachter des zähen Ringens um Formulierungen, die versuchen, der Sprache »JavaScript« gerecht zu werden.

Die aktuelle Einleitung jedoch muß offensichtlich in grober Unkenntnis des dem Sprachkern zugrundeliegenden Sprachkonzepts geschrieben worden sein. Jede Formulierung im Satz - Zitat: »Es ist eine dynamisch typisierte, objektbasierte Sprache, ähnlich den objektorientierten, jedoch ohne Polymorphie und Vererbung.« - ist falsch bis auf - Zitat: »... dynamisch typisierte ...«.

Deshalb melde ich mich hier zu Wort, um die Dikussion zur kompletten Umformulierung der Einleitung anzuregen, bevor ich durch eigenmächtiges Ändern meinerseits eine neue Kaskade an *Wiederherstellen / erneut ändern* lostrete und allgemeinen Mißmut und Unwillen heraufbeschwöre.

Die von mir vorgeschlagene und zu diskutierende Neufassung kommt folgendermaßen daher:

Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, objektorientierte aber klassenlose Skriptsprache, die dennoch allen objektorientierten Programmierparadigmen unter anderem auch - aber eben nicht ausschließlich - auf der Basis von Prototypen gerecht wird. Obwohl im Grunde eine funktionale Skriptsprache, läßt sich in JavaScript sowohl prozedural als auch rein funktional bzw. objektorientiert programmieren. ECMA 262 kann damit ohne weiteres auch als Multiparadigmensprache bezeichnet werden.

In JavaScript representieren sich alle Daten bis auf die Typen [Undefined] und [Null] bzw. bis auf die primitiven Werte [boolean], [number] und [string] als Objekte. Funktionen sind ebenfalls Objekte, deren im Funktionsrumpf gebundenen Anweisungen über den call-Operator bzw. über call-Methoden ausgeführt werden.

Gekapselte Daten sind lokale Werte bzw. Objekte einer Funktion. Diese begrenzte *Sichtbarkeit* von Daten kann bei Datenstrukturen durch ineinander verschachtelte Funktionen (Funktion in Funktion) gezielt ausgenutzt und über Referenzierungskonzepte ebenso gezielt getunnelt werden.

Schon auf dieser Grundlage läßt sich fuer alle nativen JavaScript-Objekte das Signal-Slot-Konzept implementieren, sodaß ereignisorientiertes Programmieren, auch losgelöst von DOM-Events, allein mit den Mitteln des Sprachkerns möglich ist.

Vererbung wiederum erfolgt in JavaScript ausschließlich über Delegation; entweder direkt über eine der call-Methoden oder implizit über den Objekt-Prototypen eines jeden Objekt-Konstruktors. Letztgenannter leistet dabei die Abstraktion zur Vererbung (im Sinne von *ist ein* ), während die zuerst angesprochenen Methoden der Umsetzung des Aggregationskonzepts (*hat ein*) dienlich sind.

Weitere Formulierungen, die bei Bedarf ohne weiteres übernommen bzw. angepasst werden können, finden sich auf Benutzer_Diskussion:Pseliger

so long - peterS. - 13:18, 10. Jul. 2008 (CEST)

Nach drei Tagen Stille hab' ich jetzt mal vorsichtig Hand angelegt, und hoffe, daß jemand die Änderungen (unter Entwurf) mitbekommt, diskutiert und möglicherweise auch freigibt.

so long - peterS. - 14:22, 13. Jul. 2008 (CEST)

Konvention Konstruktor-Funktionen

Hallo,

eine Javascript-Konvention besagt, dass Namen von Konstruktor-Funktionen immer mit einem Großbuchstaben beginnen sollten. Diese Konvention wird in den Code-Beispielen leider nicht eingehalten. (Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 141.12.206.239 (Diskussion • Beiträge) 10:16, 13. Nov. 2008 (CET))

Rollover-Effekte als Missbrauch?

Das ist ja wohl Blödsinn. Ich wüsste nicht warum das hervorheben des gerade aktiven Punktes eines Menüs durch farbliche Veränderung (Ersetzen der Menüpunktgrafik) einen Missbrauch und schlechten Stil darstellen sollte. Dann betreibt ein nicht gerade geringer Prozentsatz sowohl kommerzieller als auch gewerblicher Seiten Missbrauch von Javascript. Diese Behauptung ist schlichtweg unseriös und wohl von persönlichen Abneigungen des Beitragsautors beeinflusst.

Hier ist der beanstandete Abschnitt: http://de.wikipedia.org/wiki/JavaScript#Missbrauch

Letzter Punkt.

Schon weg, ich sehe da ebenso wenig Missbrauch. ···- ·-· ··· -·· ·· ··· -·- 19:02, 23. Feb. 2009 (CET)

PS: Es ist insofern 'Missbrauch', dass man den gleichen Effekt in den meisten Fällen auch ohne JS umsetzen kann (mit der CSS-Pseudoklasse :hover). li.yourclass:hover {background-image: url(hintergrund2.png);} ändert zum Beispiel die Hintergrundgrafik des überflogenen Elements (außer im Internet Explorer 6, da braucht man entweder Tricks oder muss sich wieder auf Javascript stützen). --···- ·-· ··· -·· ·· ··· -·- 11:08, 10. Mär. 2009 (CET)

Schreibweise

Mich wundert das verwendete Binnenmajuskel im Namen. Ich lese normalerweise immer Javascript, was wohl vor allem auch an hören Verbreitung liegt. Der Wortschatz stimmt da mit meiner Meinung auch überein. --87.78.32.142 18:57, 4. Mär. 2009 (CET)

JavaScript wurde von Netscape mit genau dieser Schreibweise veröffentlicht. Außerdem kann ich keine größere Verbreitung für Javascript erkennen. Sämtliche mir bekannten Bücher schreiben JavaScript und in Zeitschriften sieht es nicht anders aus. -- net 19:15, 4. Mär. 2009 (CET)

Das wir Namen in der Wikipedia an die Rechtschreibung anpassen sollte bekannt sein... wo wir wohl hinkämen wenn als Artikelnamen ECl@ss verwenden würden. Das Binnenmajuskel auch das Lesen von Texten stört sollte auch bekannt sein. Auf dieser Diskussionsseite hier wird auch oft die Schreibweise Javascript verwendet. --87.78.32.142 21:59, 4. Mär. 2009 (CET)

Ich zitiere mal aus WP:NK:

Ausnahmen von dieser Regel können in solchen Fällen gemacht werden, wo eine Anpassung nicht sinnvoll ist (z. B. c’t, iTunes), und wenn die unkonventionelle Schreibung eindeutig die üblichere Schreibung ist und diese den Lesefluss und Wortverbindungen nicht stört (z. B. LaTeX).

JavaScript ist die üblichere Schreibung und stört auch den Lesefluss nicht. -- net 00:16, 5. Mär. 2009 (CET)

Funktionlale Sprache?

"Obwohl im Grunde eine funktionale Skriptsprache"

Wo soll Javascript eine funktionale Sprache sein? Javascript ist doch ganz klar eine imperative/objektorientierte sprache. Kann das mal jemand klarstellen?

die Stichworte zum funktionalen Aspekt lauten »Lambda-Kalkül« und in diesem Zusammenhang dann »Rekursion« und »Currying« - weniger theoretisch dann auf alle Fälle »Closure«s.

und noch zwei Links zu ähnlich gelagerten Diskussionen im Forum von SELFHTML:

- klassenlose vollwertige und flexible oo auf funktionaler basis

- Grundkonzepte

so long - peterS. - 00:55, 02. Mai 2009 (CEST) (ohne Benutzername signierter Beitrag von Pseliger (Diskussion | Beiträge) )

was ein quark. brendan eich sagt dazu "I'm not proud, but I'm happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients." und "I still think of it as a quickie love-child of C and Self". man kann in JS halbwegs funktional programmieren, aber das war's dann auch: seiteneffekte sind nicht die ausnahme, sondern die regel. point-free zu programmieren ist unangenehm. objekte und prototypen spielen eine nicht ganz unwichtige rolle. -- ∂ 01:24, 2. Mai 2009 (CEST)

Statische Variablen und Objekt-Eigenschaften

Im Bereich "Öffentliche und private Methoden und Eigenschaften" wurde ein Beispiel für die Definition eines Prototypen gegeben. Innerhalb des Prototypen werden die privaten Variablen private_eigenschaft = "privat" und die private Methode private_methode... definiert und der Autor behauptet es handle sich hierbei um private Eigenschaften. Das hat mich etwas verwirrt, da meines es sich meines Wissens nach hier um statische Variablen/Methoden handelt, oder liege ich hier falsch? Mich würde interessieren ob es überhaupt möglich ist private Eigenschaften Objektspezifisch zu definieren!?

Nein, das interpretierst du falsch. In dem Beispiel wird in der prototype funktion gezeigt, dass du dort keinen Zugriff auf die privaten Variabeln hast. statische Variabel gibt es so in JS nicht. Und ja es ist möglich private attribute und Methoden zu definieren, so wie es in dem Beispiel getan wird. Struppi 11:49, 16. Mär. 2009 (CET)

Etwas Hintergrund:

function meinObjekt (parameter) {

    /* this konservieren */
    var self = this;

    /* "private Eigenschaft", lokale Variable der Konstruktorfunktion */
    var private_eigenschaft = "privat";

    /* öffentliche Eigenschaft des erzeugten Objekts */
    this.oeffentliche_eigenschaft = "öffentlich";

    /* "private Methode", ebenfalls lokale Variable der Konstruktorfunktion */
    var private_methode = function () {
        window.alert(private_eigenschaft + " " + self.oeffentliche_eigenschaft);
    };

    /* privilegierte öffentliche Methode des erzeugten Objekts */
    /* Hier wird mit dem Abschluss der Konstruktorfunktion eine Closure erzeugt, die
       ihren alten Kontext mit lokalen Variablen konserviert und so die "privaten
       Methoden" bzw. Eigenschaften noch kennt, während von außen nicht mehr darauf
       zugegriffen werden kann. Damit ist es möglich, ohne explizite Deklaration
       private Eigenschaften u. Methoden zu erzeugen.
     */
    this.privilegierte_methode = function () {
        window.alert(private_eigenschaft + " " + this.oeffentliche_eigenschaft);
        private_methode();
    };
}

// ruft die öffentliche Methode auf, die ihrerseits die Private aufruft
(new meinObjekt()).privilegierte_methode();

Siehe auch Closure. ···- ·-· ··· -·· ·· ··· -·- 15:53, 20. Mär. 2009 (CET)

Sichtbarkeit privater Eigenschaften

Im Beispiel des Abschnitts "Öffentliche und private Methoden und Eigenschaften" wird in einer nicht-privilegierten Methode der Zugriff auf eine private Eigenschaft mittels typeof(private_eigenschaft) versucht. Das dies nicht funktioniert, wird zwar im Text erklärt, aber das Codebeispiel irritiert, weil beim Lesen die Vermutung aufkommen könnte, man könne wenigsten den Typ der privaten Eigenschaft ermitteln. Deshalb habe ich mir mal erlaubt an die Codezeile den Kommentar 'gibt "undefined undefined" aus' anzuhängen, obwohl das später im Text noch erklärt wird. (nicht signierter Beitrag von 78.43.35.44 (Diskussion | Beiträge) 11:58, 15. Mai 2009 (CEST))

Wo bleibt die Kritik

an Javascript? Einen hauptsächlichen Nachteil kann ich sofort nennen: Es verzögert den Seitenaufbau und die Bedienbarkeit von Internetseiten auf nicht mehr ganz taufrischen Computern bis zur (Un-)Zumutung. Paradebeispiel ist ebay, dessen Seiten so quälend langsam geworden sind, daß man damit nicht mehr sinnvoll arbeiten kann. Der Taskmanager zeigt ein manchmal fast schon minutenlanges Gerödel von 50 bis teilweise über 90 % (!) Prozessorauslastung nur des Threads des Internet-Explorers an, der mit ebay beschäftigt ist. Ich frage mich, was zum Teufel dort im Hintergrund alles zu "erledigen" ist (vermutlich beschäftigt sich die Seite überwiegend mit sich selbst). Anzeigen, die Hauptfunktion jedes Webbrowsers, erfordern allein nie und nimmer einen solchen Rechenaufwand. (nicht signierter Beitrag von 89.244.66.7 (Diskussion | Beiträge) 12:42, 22. Jun. 2009 (CEST))

Das hat mit der Skriptsprache wenig zu tun, das liegt daran dass die Webseite von eBay schlichtweg grausam geschrieben ist und der Internet Explorer eine vollkommen unzureichende JavaScript- bzw. JScript-Engine besitzt. Alle alternativen Browser (Mozilla Firefox, Safari, Google Chrome und Opera) sind hier schlichtweg um das mehrfache performanter, Microsoft hinkt auch weiterhin massiv in Sachen Performance, Standardkompatibilität und Innovationen hinterher. --Vanger ^!–!? 13:26, 22. Jun. 2009 (CEST)

Kritik steht im Abschnitt JavaScript#Missbrauch. Deine spezielle Kritik an den Programmierkünsten der EBAY-Verantwortlichen lässt sich hingegen nicht verallgemeinern.--Fritzbruno 19:00, 22. Jun. 2009 (CEST)

Ja, stimmt, mit Opera läßt sich ebay besser bedienen, scheint also auch am Browser zu liegen. Außerdem ist amazon auch eine in dieser Hinsicht "schlimme" Internetseite, denn die ist, wenn man in ihr mit dem Internet-Explorer surft, ähnlich träge wie ebay.... -- 89.244.65.85 21:17, 16. Jul. 2009 (CEST)

weder ebay noch amazon sind hier Thema - bitte listet hier nicht noch mehr Erfahrungen mit irgendwelchen Seiten auf--Fritzbruno 06:59, 17. Jul. 2009 (CEST)

weiterführender Weblink?

Kann mir jemand das Weiterführende an dem ebusiness-akademie.de-Link zeigen? ich finds nicht. --217.84.18.237 13:31, 2. Jul. 2009 (CEST)

Befehlsübersicht

Schön fände ich auch eine Befehlsübersicht - der Befehle, die in den wichtigsten Browsern unterstützt werden. Wie z. B. hier: http://www.office-loesung.de/ftopic336244_0_0_asc.php Das wäre doch schon einmal ein Anfang.

Gruß Hans-Jürgen -- 88.68.212.25 15:07, 21. Sep. 2009 (CEST)

so etwas gehört eher in ein Tutorial, nicht in Wikipedia.--Fritzbruno 20:20, 21. Sep. 2009 (CEST)

dynamische vs. schwache Typisierung

Im Artikel steht "JavaScript ist dynamisch typisiert, d. h. der Datentyp einer Variablen kann sich während der Ausführung eines Scripts ändern". Werden hier nicht die Begriffe dynamische Typisierung und schwache Typisierung verwechselt? Dynamische Typisierung bezeichnet doch, dass der Typ einer Variablen zur Laufzeit und nicht zur Übersetzung bestimmt wird. Die Möglichkeit, dass eine Variable verschiedene Typen während des Programmablaufs annehmen kann, wird mit schwacher Typisierung bezeichnet. Was ist denn hier gemeint? -- Freischlad 10:40, 8. Okt. 2009 (CEST)

CommonJS

Warum wurde der Link zu CommonJS entfernt? Dabei handelt es sich doch um eine Spezifikation einer Standardbibliothek. Nicht um eine Standardbibliothek, sondern nur eine Spezifikation (gibt diverse Implementierungen). --Wikieditoroftoday (disk.) 21:46, 24. Okt. 2009 (CEST)

Ich wollte mich im Spec-Abschnitt auf JS beschränken, daher hab ichs (wie auch E4X) rausgenommen. Ist das Projekt offiziell? Es sieht so oder so artikelrelevant aus, erst recht wenn einzelne Frameworks auch Artikel haben. Sobald es hier einen Artikel hat, kann man es auch im Fließtext verlinken. --Seine Idempotenz 22:04, 24. Okt. 2009 (CEST)

Da es zur Zeit nur eine Version 0.1 gibt, weiß ich nicht, ob es sich lohnt einen Artikel dafür anzulegen. Hier wird zu schnell gelöscht. Aber man könnte es bereits so in dem Artikel einbauen. --Wikieditoroftoday (disk.) 22:25, 24. Okt. 2009 (CEST)

So hatte ich mir das gedacht. Gute Nacht :-) --Seine Idempotenz 01:41, 25. Okt. 2009 (CEST)

JS 1.8

Könntet ihr die Codebeispiele euklid und ggTbitte wieder auf gängige ECMAScript-3-Syntax umstellen. Die proprietäre JS-1.8-Kurzschreibweise zu erwähnen mag am Rande Sinn machen, aber ein Beispiel für eine JS-Funktion sollte nicht nur im Spidermonkey funktionieren. Bitte in den Beispielen an etablierte JS-Syntax halten. Irgendwann war die Funktion ggT auch mal menschenlesbar. Durch die ganzen Programmierkniffe hat sie jegliche Anschaulichkeit verloren -- 88.130.125.170 14:00, 11. Nov. 2009 (CET)

In 1.5-er Syntax mit Boilerplate:

function euklid (a, b) {
	return b ? euklid(b, a%b) : a
}

function ggT () {
	return (function (args) {
		return !args[1]
			? (function () {
				return args[0] || 0
			})
			: (function () {
				return euklid(
					args[0],
					ggT.apply(null, args.slice(1))() )
			})
	})(Array.prototype.slice.apply(arguments))
}

Besser? --Seine Idempotenz 14:45, 11. Nov. 2009 (CET)

PS: Funktionales JS schreibt sich mit 1.8 nunmal schöner, die 1.5er-Syntax hat dort einfach zu viel Ballast. Und wer die Funktion, egal in welcher Syntax, versteht, hat damit einen großen Teil von JS verstanden. Auch kleine Funktionen (Tip: lesenswerter Link) können es in sich haben, und kompakte Beispiele ziehe ich in einem Wikipediaartikel vor. (Okay, bei Perl wäre das was anderes, aber JS ist nicht Perl.) --Seine Idempotenz 15:01, 11. Nov. 2009 (CET)

JScript forward

Könnte man für JScript eine eigene Seite machen? Mich interessiert nun halt die alte MS-Version und nicht Sun...

Gibt es doch? Siehe JScript. --Seine Idempotenz 21:14, 4. Feb. 2010 (CET)

Datentypen

http://de.wikipedia.org/w/index.php?title=JavaScript&diff=next&oldid=67085253

Diese Änderung halte ich nicht für gelungen. Dabei sind essentielle Informationen herausgefallen, die zum Verständnis von JS wichtig sind. Man sollte grundsätzlich zwei Sachen unterscheiden:

• Die tatsächlichen internen ECMAScript-Typen,
• die Rückgabe des typeof-Operators.

Der typeof-Operator ist ein »Bad Part« von ECMAScript, damit kann man nicht erklären, wie ECMAScript tatsächlich funktioniert. Ich bin der Meinung, die Beschreibung der Typen einer Programmiersprache sollte nicht bloß an der (im Falle von ECMAScript irreführenden) Oberfläche kratzen. Wenn hier von Datentypen die Rede ist, sollte das konsistent zum Begriff »Type« im ECMAScript-Standard erfolgen.

Wirklich grundlegend ist die Unterscheidung zwischen Primitive Values und Objects. Nur wenn man den verstanden hat, sind auch die Datentypen JavaScripts verständlich und typeof sinnvoll nutzbar.

Alle anderen Werte - reguläre Ausdrücke, Arrays und der Wert null inbegriffen - sind vom Typ object.

Null ist vom Typ null. Es ist kein Object (im Sinne von Primitive vs. Object), auch wenn typeof null dummerweise "object" zurückgibt. Das neue Beispiel mit new String() macht ein Fass auf, das gerade dieser Edit geschlossen hat, indem er Primitives vs. Objects nicht mehr erklärt. Das Beispiel ist eher verwirrend, denn für new String udgl. gibt es keinen praktischen Anwendungsfall.

Da müsst ihr euch einfach mal entscheiden, was unter »Datentypen« laufen soll: Entweder die Beschreibung der ECMAScript-Datentypen oder die Beschreibung des typeof-Operators, der einem über erste keine zuverlässige Auskunft gibt. -- molily 01:11, 18. Jan. 2010 (CET)

Meine Absicht war in dem edit, von Otto Normalentwickler und seinen Bedürfnissen auszugehen: und der benutzt halt typeof. Daß null intern irgendwo ein eigener Typ ist, ist ihm ziemlich egal - weil die Sprache es ihm durch nichts verrät... Daß new String() nicht sinnvoll ist, ist klar - aber man findet es noch oft genug in freier Wildbahn. Das Beispiel war dazu gedacht zu zeigen, warum es halt in der Wirkung nicht das selbe ist wie ein Stringliteral. Aber du hast recht, wahrscheinlich wäre ein extra Unterabschnitt zu "typeof" besser gewesen. Eigentlich war's schön, wie die Typen vorher kurz und bündig erwähnt wurden. -- Fusselwurm 11:34, 6. Feb. 2010 (CET)

Was wichtig ist

Ich finde die Frage, ob Java von bestimmten Puristen als objektorientierte Programmiersprache angesehen wird völlig irrelevant. JavaScript enthält zumindest einige Features objektorientierter Programmiersprachen.

Wichtig ist: JavaScript ist die Skriptsprache für Skripte, die in HTML eingebunden werden und vom Browser ausgeführt werden. Die Sprache ist standardisiert und der Standard ECMA-262 wird heute von praktisch allen gängigen Browsern unterstützt. Daher ist JavaScript die Programmiersprache zur Ausführungen von Berechnungen, wie Überprüfungen von Formulareingaben, die auf dem Rechner des Anwenders (Client) ausgeführt werden sollen.

Ich kann eigentlich nicht erkennen, dass der Artikel dringend überarbeitet werden muss. Benutzer:Fsswsb 30.05.06

Besteht vielleicht die Möglichkeit eine Tabelle in die Seite zu ein zu pflegen, aus der ersichtlich ist, welche der gängigsten Browser welche ECMA Version mindestens unterstützen? Danach hab ich nämlich gerade gesucht und leider nicht so wirklich was gefunden. --Daimonion1980 14:59, 15. Mär. 2010 (CET).

Eine solche Tabelle wäre nicht sonderlich aussagekräftig, denn die in den Browsern enthaltenen JS-Engines unterstützen alle weitesgehend ECMAScript 3. Der Standard ist von 1998. Manche Browser unterstützen bereits einzelne Neuerungen aus ECMAScript 5, welcher letztes Jahr erschienen ist.

Microsoft hat kürzlich ein Dokument veröffentlicht, welches die Abweichung ihrer JScript-Implementierung von ES3 detailliert beschreibt. Im Prinzip unterstützen aber alle Browser die Grundzüge von ES3. -- molily 02:55, 8. Apr. 2010 (CEST)

Exzellenter Artikel

Die Autoren haben wirklich sehr gute Arbeit beim Verfassen des Artikels geleistet. Weiter so. ;)

84.184.189.92 01:57, 4. Mai 2010 (CEST)

Quellcode verschleiern

Was ist so schlimm daran seinen Quellcode vor den Benutzern zu verbergen? Deinen Backend Code gibst Du ja auch nicht her? Finde der Punkt sollte raus. (nicht signierter Beitrag von 84.184.179.139 (Diskussion | Beiträge) 19:36, 5. Mai 2010 (CEST))

Alle Techniken, die auf JavaScript bauen, funktionieren ohne selbiges nicht, in diesem Fall wäre eine per JS verschleierte Seite einfach unbrauchbar. Insofern ist dieser Punkt hier berechtigt! HTML/CSS ist mit Programmcode nicht zu vergleichen.--Fritzbruno 16:02, 6. Mai 2010 (CEST)

JavaScript aktiv ?

Wie stelle ich fest, ob bei mir JavaScript aktiv ist ? Anlaß für meine Frage ist dies hier. Die Hilfseite hat mir nicht weitergeholfen. --michelvoss 14:57, 24. Mai 2010 (CEST)

tippe folgendes in die Adresszeile des Browsers: javascript:alert("aktiv"). Drücke die Enter-Taste.

wenn dann ein Fenster mit dem Text "aktiv" erscheint ist JavaScript aktiviert.--Fritzbruno 15:45, 24. Mai 2010 (CEST)

Danke!

Hab' garnicht geahnt, daß die Lösung so einfach ist. Deshalb gleich auf Hilfeseiten als ALLERERSTE Antwort unter J verewigt und zusätzlich getwittert, damit Wikipedia noch ein paar hundert Nutzer mehr bekommt.--Michel Voss 16:37, 24. Mai 2010

Anfängerversion

24. Mai 2010

Eine Meisterleistung wäre es wenn es Autoren schaffen würden, eine kurze Anfängerversion dieses Artikels zu erstellen.

"JavaScript ist eine Skriptsprache, die hauptsächlich für das DOM-Scripting in Web-Browsern eingesetzt wird" zwingt Menschen, die diese Fachsprache nicht "beherrschen", sich immer weiter durchzuklicken, um den Inhalt zu verstehen. --Michel Voss 16:01, 24. Mai 2010 (CEST)

Unterstützte JavaScript Version von Chrome

Hallo, mir ist nur eine kleine Sache aufgefallen und zwar wird in der Liste der Browser mit JavaScript unterstützung angegeben, dass Google Chrome JavaScript 1.7 ab Version 1.0 unterstützt. Das stimmt leider so nicht ganz. Es werden leider nur ein paar Sprachfeatures von 1.7 unterstützt allerdings nahezu alle von 1.5

Beispiel: In 1.7 ist spezifiziert, dass Arrays eine indexOf Methode haben, diese unterstützt Chrome allerdings nicht. (Es gäbe noch weitere Beispiele, will aber niemanden langweilen :-) )

-- Boinji 09:37, 28. Jul. 2010 (CEST)

Codebeispiel mit Katze

Wer hat sich bitte dieses gemeine Code-Beispiel einfallen lassen in dem eine Katze getötet wird? Wäre toll wenn sich jemand kreativer mal ein besseres ausdenken könnte :/

-- blah (nicht signierter Beitrag von 86.33.222.40 (Diskussion) 20:46, 30. Jul 2010 (CEST))

Kopiervorlage Internetquelle

Kopiervorlage Internetquelle scheint hier unbekannt, deshalb weigere ich mich diese Version als gesichtet zu kennzeichnen. (Unterschied | Versionen) . . K! JavaScript‎ [sichten]; 21:29 . . (+18) . . Michelvoss (Diskussion | Beiträge) (→Entwicklung)--michelvoss 23:44, 15. Aug. 2010 (CEST)

Duck Typing

Meiner Meinung nach ist Duck Typing keine Spracheigenschaft, sondern eine Programmiertechnik, und sollte daher aus dem Infokasten entfernt werden -- 95.113.18.98 23:50, 30. Aug. 2010 (CEST)

Damit liegst du aber daneben. Folge den Link zur Duck Typing und lies es mal sorgsam durch. Verwirrt war ich nur über das dort Gelesene. Eigentlich wird darunter nämlich verstanden, dass zur Laufzeit einer Variable unterschiedliche Typen/Objekte zugeordnet werden können. Der Interpreter prüft dann zur Laufzeit ob diese Operation im aktuellen Kontext möglich ist und führt diese aus.--178.24.70.200 09:21, 15. Sep. 2010 (CEST)--178.24.70.200 09:22, 15. Sep. 2010 (CEST)

Einleitung

"Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache, die dennoch allen objektorientierten Programmierparadigmen unter anderem auch – aber eben nicht ausschließlich – auf der Basis von Prototypen gerecht wird."

Dazu gleich mehrere Fragen:

• Was soll mit "Sprachkern" gemeint sein? Das habe ich noch nie gehört.
• Wieso "modern"? "schlank"?
• "dennoch"? So wie der Satz dasteht, bedeutet das: "Obwohl der [...] Sprachkern von Javascript eine [...] Skripsprache beschreibt, wird diese allen OOP Programmierparadigmen [...] gerecht." Das kann ja wohl nicht gemeint sein, oder?

Ja, hier muss man etwas kleinlich sein, weil der erste Absatz der wichtigste ist, und inhaltlich frei von derlei Obskuritäten sein sollte -- 95.113.18.98 00:22, 31. Aug. 2010 (CEST)

der letzte Teil ist sogar wiedersprüchlich. Wirkliches OOP kennt selbst auch keine Klassen, sondern wenn dann nur Klassenobjekte, die nichts anderes als Objekte sind (Objekte einer "Klasse" werden erzeugt, in dem man dem Klassenobjekte sagt, ich möchte ein Objekt deiner "Klasse" haben. Es gibt demnach keinen new Operator). Weiter sollte man auch im Artikel schreiben, dass der new Operator in JS nicht die Funktion eines klassischen new erfüllt, sondern eher eine Copy-Methode auf das Prototype eines Objektes ist. Modern ist JavaScript, weil es eine protypen orientierte Sprache ist. Schlank, weil JavaScript wirklich sehr schlank aufgebaut ist, nahezu typlos, wenige Operatoren, etc... Ich würde shcon fast so weit gehen und JavaScript nicht als objektorientiert, sondern als prototypenbasiert zu kennzeichnen. Folgende Teile von Paradigmen fehlen:

* (Polymorphie) Überladung von Operatoren und Methoden (bedingt, WebKit unterstützt dies, Mozilla nicht)

* (Datenkapselung) Vererbung privater Variablen/Methoden nur über Umwege möglich

--Karolherbst 16:03, 29. Okt. 2010 (CEST)

AOP in JavaScript

AOP ist an sich kein offizielles Paradigma in JavaScript, jedoch lässt sich in JavaScript sehr einfach jedoch auch eingeschränkt aspektorientiert programmieren.

var oldAlert = window.alert;

window.alert = function newAlert(str){
	document.write(str);
}

Hier wird die ganz gewöhnliche alert methode am window objekt überschrieben. Wenn man weiter ins AOP geht, dann macht man folgendes:

Function.prototype.oldCall = Function.prototype.call;
Function.prototype.call = function newCall(){
	alert('Methode ' + this.name + ' wird ausgeführt');
	this.oldCall();
}

Hier wird sogar was bei jedem Funktionsaufruf etwas eingeschläußt. Da man hier direkt im Functionobjekt ist, weiß man welches Objekt eine Methode aufruft und an welchem Objekt dies geschah. Hiermit können die in AOP üblichen Patterns für Methodenaufrufe umgangen werden und das gleiche Ergebnis erzielt werden. Ich weiß, dass dies eher selten pder fast gar nicht getan wird. Jedoch ist das ein sehr schönes Beispiel, was mit Prototypenbasierte Programmierung alles möglich ist. Für mich ist der Artikel etwas zu viel nach einem falschen OOP Ideal geschrieben und zeigt nicht wirklich, was an JS so mächtig ist. Selbst im Artikel über Prototypenbasierte Programmierung steht kein Wort über das überschreiben von bestehenden Methoden. --Karolherbst 15:40, 8. Nov. 2010 (CET)

eigenschaft der sprache

ich finde diese beschreibung wie 99% aller beschreibungen von js an der sprache vorbei geht. javascript ist nicht in den rahmen der normal prozeduralen oder oop einzuordnen. kasnn zwar dahin verbogen werden, sie ist allerdings vielmehr verwand mit ki sprachen wie lisp. siehe eure eigene referenz: http://de.wikipedia.org/wiki/Scheme javascripts herausragende eigenschaft, characteristikum ist das /lernfähige/ objekt("the mutable object"). lernfähig im sinne der ki.

wir haben ein objekt das nichts kann

A={}

und ein Object das eine fähigkeit und eine eigenschaft hat.

B={
 'eigenschaft':1,
 'faehigkeit':function(){alert('ich kann was');}
}

nun kann A die fähigkeit von B /lernen/:

A['faehikeitvonb'] = B['faehigkeit'];

damit macht prototyping auch sinn! js ist eine ki sprache von grund auf und kann zwar anderes imitieren. das zu tun und zu vergessen was js wirklich ist, führt aber zu den üblichen problemen. ausgezeichnetes beispiel für eine komplette missachtung der charakteristik der sprache ist der satz:

JavaScript ist dynamisch typisiert, d. h. der Datentyp einer Variablen kann sich während der Ausführung eines Scripts ändern, was manchmal zu Fehlern bzw. unerwünschten Effekten führt.

der wert einer "variable" kann sich nicht nur ändern: es ist eines der herausragenden merkmale der sprache. zu fehlern führt von etwas anderem aus zu gehen.

delete( Objekt.eigenschaft);

eine abfrage der eigenschaft führt zu dem exakt natürlich richtigen ergebnis: "weiss nicht was das ist"('undefined'). "das objekt hat vergessen". damit reagiert js sehr ähnlich zu einem realen objekt. es liegt natürlich in der verantwortung das sinnvoll einzusetzen. deswegen braucht eine sprache wie js auch diesen zusätzlichen wert 'undefined' - weil ein objekt eben über eigenschaften verfügen kann oder nicht und sich das per "lernen und vergessen verändert. im browser ist es gut, dass js diese eigenschaft hat. dadurch lässt sich ein browser an bedürfnisse anpassen, eigenschaften und funktionen nach bedarf hinzugefügt und entfernt werden.

ich habe mir gerade den englischen artikel angesehen: wäre vielleicht das beste diesen artikel durch eine übersetzung des englischen zu ersetzen. ist weniger irreführend und falsch als dieser deutsche. vielleicht macht es sinn den artikel auf das wesentliche zu reduzieren(damit auch fehler zu umgehen). wer javascript lernen will wird das nicht über wikipedia tun.

private (nicht signierter Beitrag von 84.57.52.143 (Diskussion) 01:19, 5. Jan. 2011 (CET))

Den Artikel zu zerstören, um ihn durch eine sklavische Übersetzung aus dem Englischen zu ersetzen, ist so ziemlich der armseligste Vorschlag, den ich seit Langem gelesen habe. Leistung statt Abschreiben! Vielfalt statt Nachäfferei! Also: Nein, es wäre nicht besser, den Artikel durch eine Übersetzung des englischen Wikipedia-Artikel zu ersetzen. Außerdem wäre es wahrscheinlich nur schlechtes Deutsch. --Parzi 01:22, 6. Jan. 2011 (CET)

deutsch kan ich nicht glänzen... leider. es ging mir nicht um sprache sondern inhalt und richtigkeit. vielfalt ist da nicht unbedingt zielführend. hier gibt es so etwas wie richtig(er) und falsch(er). inhaltlich ist das englische richtiger und das deutsche falscher(böse könnte auch geagt werden themaverfehlung).

ich muss ausholen um zu erklären: javascript ist als richtige sprache mit einem konzept entworfen. das wurde kaum verstanden. dokumentation zur sprache wurde fast ausschließlich von leuten geschrieben, die sie nicht verstanden haben. mindestens 10 jahre gab es kein einziges js buch, dass die sprache wenigstens vom ansatz richtig beschrieben hat. mittlerweile hat sich das geändert, die sprache wird mehr und mehr verstanden. andere sprachen übernehmen mehr schlecht als recht konzepte aus js(reflection frameworks). die falschen bücher sind leider geblieben und nur wenig brauchbares kommt langsam(am besten sind beschreibungen diverser toolkits). den wohl bekanntesten, öffentlich hörbaren, rundumschlag machte crockford von yahoo und schafte es der welt etwas verständlich zu machen. allerdings machte er auch einen großen fehler(sieht er mitlerrweile auch so - siehe bemerkung auf seiner seite). der fehler: er versuchte die sprache in konzepte zu pressen, die für sprachen mit klassen(starre, undynamische objekte, instanzen nach "blaupausen" erstellt, frühes linken. im völligen gegensatz zu js.) entwickelt worden sind. er hat erst der sprache klassen aufgepfropft und dann klassisches oop für sprachen mit klassen genutzt(aber zumindest richtig). folge ist, das framworks seine auffassung nachahmen. soweit, dass crockfords ansätze nun wiederum in js aufgenommen werden und js klassen bekommt. auch die create methode die kommen wird ist aufnahme einer crockfort idee. völlig ohne bewertung ob das gut oder schlecht ist(ist einfach so), ist es bezeichnend, dass js verändert wird um programierern gerecht zu werden, die sie verwenden, wie sie eigentlich nicht funktioniert(e). wie gesagt nicht unbedingt schlecht, dadurch hat js eine sehr lebendige weiterentwicklung. paradigmen sind schön, nur wo js sitzt ist ein loch in den paradigmen in europa. in den usa ist es wenig anders da dort informatik studenten traditionell oft mit lisp anfangen zu programmieren. das multiparadigmisch, wie im artikel dargestellt kommt zwar, weil in die sprache paradigmen, die angewendet werden(wenn es nicht originär geht, verbiegt man die sprache eben dahin: das geht mit js, was eben ein wichtig charakteristikum der sprache ist) in sie aufgenommen werden, sie folgt originär einem speziellen konzept, dass von scheme oder self kommend zu etwas fassbar neuen entwickelt wurde. wie gesagt, das wohin js konzipiert wurde finden ganz langsam eingang in andere sprachen(stichwort reflection). sofern war js mit seinem ansatz zumindest in teilen seiner zeit wohl zu sehr vorraus(ob zum guten oder schlechten) um verstanden zu werden. nach so viel missverständnis ist es bei dieser sprache m.e. besonders wichtig von ihr auszugehen und nicht von etwas andern um die verwirrung nicht noch größer werden zu lassen.

weiter ist es mir eigentlich egal, was in wikipedia steht. allerdings stosse ich auf leute, die mit wikipedia argumentieren und darauf verweisen statt auf verlässliche quellen. in sofern sehe ich eine verantwortung bei wikipedia dinge inhaltlich richtig darzustellen. viele worte: ja, ein versuch verständnis zu finden. ich will es nicht ganz weg lassen "vielfalt" zu hören oder "sklavisch", bei der darstellung eines sachverhaltes, der real existent ist, lässt mich den kopf schütteln(ist wie "bloss nicht sklavisch eine realität akzeptieren, wir bauen uns unsere eigenen realitäten, phantasievoll vielfältig"). (nicht signierter Beitrag von 88.65.142.43 (Diskussion) 12:38, 8. Jan. 2011 (CET))

Du hast geschrieben: ich will es nicht ganz weg lassen "vielfalt" zu hören oder "sklavisch", bei der darstellung eines sachverhaltes, der real existent ist, lässt mich den kopf schütteln [...].
Ich habe den Eindruck, dass bei viele Wikipedia-Zuträger dazu neigen, das englischsprachige Wiki zu überschätzen und es unreflektiert als Referenz nutzen. Das erinnert mich daran, dass ich kürzlich einer Kurzpräsentation beiwohnte, in der jemand den Entwurf eines Grundlagenpapiers für eine Institution vorstellte. Er erklärte, dass man sich weitgehend allgemeinverständlich ausdrücken wollte, damit es auch jeder verstehe und schloss seine Präsentation damit ab, dass er das "Mission Statement" aus dem Entwurf vorlas und an der Wand zeigte. In diesem bemüht allgemeinverständlichen Dokument stand also wirklich "Mission Statement", was offensichtlich schon im Englischen ein farbloser, quasi verwaltungssprachlicher Ausdruck ist, etwa mit "Aufgabenfeststellung" zu übersetzen. Das Beispiel soll sagen: Es ist oft wenig hilfreich Inhalte – oft bloß, weil es bequem erscheint – aus englischen Dokumenten unreflektiert zu übernehmen. Besser scheint es mir selber nachzudenken. Ich sehe aber, dass immerhin Du vor allem inhaltliche Gründe anführst, insofern gestehe ich ein, Dich vielleicht unterschätzt oder falsch eingeordnet bzw. mich etwas zu heftig ausgedrückt zu haben. -- Parzi 20:52, 8. Jan. 2011 (CET)

BTW: Nach aktuellen deutschsprachigen JavaScript-Büchern habe ich mich kürzlich auch wieder einmal umgesehen. Auf Deutsch gibt es tatsächlich seit Langem nur einige – teilweise erweiterte – Neuauflagen von Büchern der hierzulande erfolgreichsten JavaScript-Autoren (Steyer, Koch, Wenz, Seeborger-Weichselbaum u. dgl.). Anscheinend nichts wirklich Neues oder Tolles. Aber immerhin soll im März die deutsche Übersetzung eines Buches von Microsoft-Press kommen. Vermutlich werde ich es mir kaufen. Kennst Du diesen Microsoft-Titel aus dem Englischen? -- Parzi 17:53, 8. Jan. 2011 (CET)

tip: /be. brendons seite. http://brendaneich.com/ die quelle. keine abgehobene oder langatmige whitpaper ohne ihnhalt sondern sehr konkret und lebendig. dort auch auch http://blip.tv/file/3837048. sehr schön, .. [ btw er fast darin am anfang die sprache zusammen: 1rst class functions, closures, prototypes, objects, arrays. davon finden lediglich closures erwähnung in diesem artikel... ]

b) http://www.ecmascript.org vor allem auch die mailing listen(kathegorie community).

c) doug crockford. kritisch betrachten! brendon wird manchmal recht deutlich gegen ihn. aber immerhin hat er es geschaft, dass die leute ihm glauben und ein paar seiner(nach /be fixen?) ideen in js eingeflossen sind. http://www.crockford.com/

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 21:08, 8. Jan. 2011 (CET))

noch ein letztes, typisches object erstellen in js:

        var Lampeprototyp={
            'an':false,
            'anschalten':function(){ this.an = true; }
        };
        var lampenbaubeschreibung = function(){
           this.ausschalten=function(){this.an = false; }
        };
        lampenbaubeschreibung.prototype = Lampeprototyp;
        Lampe = new lampenbaubeschreibung();
        Lampe.ausschalten();
        Lampe.anschalten();

es moduliert damit(ob das gut oder schlecht ist:?) im gegensatz zum klassenansatz die realität nach. wenn ich mir in der realität eine Lampe bauen lassen will kann ich einem handwerker entweder eine beschreibung geben oder einen prototypen, nach dem die Lampe gebaut werden soll oder beides. genau so funktioniert js. genau das mache ich oben: ich habe einen Lampenprototypen und zusätzlich zu dem will ich noch ausschalten können. also fertige ich eine beschreibung an, in der steht, dass ausschalten möglich sein soll. zusätzlich hänge ich den lampenprototyp an die beschreibung. dann gebe ich die beschreibung an einen handwerker: new. zurück bekomme ich eine Lampe, wie ich sie wollte und kann sie auch so nutzen. der klassenansatz macht komplett anderes. der klassenansatz erklärt wie objekte aussehen auf einer metaebene und nicht im "leben"(reflection springt in die lücke). jetzt habt ihr genug anregungen und ich lasse euch mindestens ein halbes jahr in ruhe überlegen was ihr machen wollt oder nicht. viel spass. (nicht signierter Beitrag von 88.65.142.43 (Diskussion) 18:46, 9. Jan. 2011 (CET))

"private" Eigenschaften

folgendes geht auch. Finde ich für das Verständnis besser, da man keine Notationsweisen vermischt und sich nur auf eine Sache konzentrieren muss (function() oder this.func = function() ).

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

	this.toeten = function () {
		lebensZahl -= 1;
		alert(maunz());
	}
};
var otto = new Katze();
otto.toeten(); // miau

--Karolherbst 14:42, 2. Nov. 2010 (CET)

siehe auch:

http://wiki.ecmascript.org/doku.php?id=strawman:private_names

auch die frage, welchen zweck "private" erfüllen soll. abstraktion, wie bibliotheken, die für interne veränderungen offen bleiben wollen und ein interface garantieren. an dem zweck festgehalten gibt es vielfältige möglichkeiten das zu erreichen. (nicht signierter Beitrag von 84.57.0.184 (Diskussion) 19:04, 5. Jan. 2011 (CET))

nebenbemerkung didaktisch ist es vielleicht noch besser generell die schreibeweise zu nutzen:

 
 var handle = function()...
 this.handle = function()... 
 objekt.handle = function()
 ...

me wird dadurch gerade in so einem beispiel klarer, was gemacht wird. es nimmt der funktion den touch besonders zu sein. var handle = "hallo"; und var handle = function(); macht m.e. die analogie greifbarer(javascriptiger: latebinding!).

noch eine idee didaktischer natur: statt Katze, ein kleingeschriebenes verb. es ist eine funktion. selbst mit new bleibt es lediglich ein konstruktor für eine katze, ist selber aber keine(und klassen gibt es in js sowieso nicht und darin besteht die verwechslungsgefahr). var katze_bauen=function() gäbe mit new katze_bauen() sinn. die funktion Katze ist keine katze sondern erstellt eine. sind arbeitschritte, die zum erstellen nötig sind. es ist eine factory für katze, wenn du so willst. vorallem aber keine katze. endlich bleibt der ausführungskontext erhalten aber die funktion Katze() ist weder der ausführungskontext noch ist es eine katze. auch das objekt "Katze()" ist keine katze. da herrscht viel verwirrung, daher der vorschlag. das ist wirklich "lediglich" eine funktion, die was "tut". im zusammenhang mit new bekommt sie das noch unfertige objekt und darf daran herum basteln.(typische verwirrung[falsch!] z.b.: "katze=new Katze(); katze.prototype=unsin" oder ähnlicher unsin...)

illustriert(geht leider so nicht mit allen browsern, __proto__ ist nicht überall zugänglich - ist aber damit plastischer.):

 
Tier={ 
     pfote:4,
     auge:{
        linkes_auge:1
     }
}

Hund={
 __proto__:Tier
}
Katze={
 __proto__:Tier
}

mit konstruktor und new passiert das gleiche, so sieht man nur mehr. wenn ich nun Hund.pfote abfrage bekomme ich die variable von tier. wenn ich Hund.pfote=3 setze, dann wird eine /zusätzliche/ variable in Hund /erzeugt/ die pfote von Tier überdeckt. in folge wird danach eben der wert dieser neuen variable zurück gegeben. beim erstellen von Hund wird die variable aber noch nicht neu erzeugt, sondern einfach die originale von Tier genommen(sprache mit klassen erzeugen die membervariable mit neu bei der konstruktion, js nicht). mit Hund.auge.linkes_auge=5 passiert genau das zu erwartende, nämlich Katze.auge.linkes_auge ist damit auch 5. genau so funktioniert konstruktor+prototyp. der prototyp wird nicht neu erzeugt. es wird einfach auf die vorhandene variable zugegriffen. schreiben wird die variable allerdings im neuen objekt angelegt. normal ist das verhalten von js effizient und variablen neu erzeugen solange auf sie nur lesend zugegriffen wird ist reiner overhead. ein erzeugen "on demand" ist gut. eine call kette in konstruktoren, so dass die objekte neu erzeugt werden(immitieren von klassen - richtig), ist generell nicht so gut aufgrund des overheads. hoffe das macht es ein bischen klarer. alles "first class". vielleicht noch call kette(simulation von klassen) ist so was:

 
var konstruktor_super = function(){
  this.blarb=
}
var konstruktor_next = function(){
  konstruktor_super.call(this,...)
  this.bluf=
}
var konstructor_further = function(){
   konstruktor_next.call(this,...)
 this.blaf=
}
...
//abgeleitetes objekt erstellen:
var objekt = new konstructor_further();
//z.b. superobjekt selber erstellen
var superobjekt= new konstruktor_super();

(nicht signierter Beitrag von 84.57.21.163 (Diskussion) 11:52, 15. Jan. 2011 (CET))

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 14:02, 8. Jan. 2011 (CET))

das wäre ein beispiel für eine bibliothek, die private braucht zur abstraktion(kein new!!):

 
    var publicobject={
      //... öffentliches interface   
      //.. alles was hier steht ist direkt verwendbar durch andere die es einbinden
    };

    (function(){
        //private geschichten was hier steht ist nicht direkt verwendbar durch leute die einbinden

       var a = 5;
       var b = "blah";
       // es kann aber kontrolliert verfügbar gemacht werden.
       publicobject.Agetter=function(){
           return a;
       };
    })();

(nicht signierter Beitrag von 88.65.142.43 (Diskussion) 20:54, 9. Jan. 2011 (CET))