Diskussion:JavaScript

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)

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)

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)

---

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.

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)

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)

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)

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

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 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

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)

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.

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)

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)

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)

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)

JScript forward

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

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)