Diskussion:Prototypenbasierte Programmierung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Wieso ist Actionscript eine Prototypenbasierte Programmierumgebung? Es gibt doch Klassen!!!

Ja, aber die Klassen sind nachträglich hinzugekommen (und vermutlich, da hab ich gerade keinen Überblick, intern über Prototypen implementiert) - der Ursprung von ActionScript liegt in ECMAScript 1, und das ist eben prototypen-basiert Warp 14:33, 14. Aug. 2008 (CEST)[Beantworten]

Das Code-Beispiel zum Klonen ist falsch! Es existiert hier immer noch eine Prototype-bezogene Kopplung! (nicht signierter Beitrag von 92.194.21.124 (Diskussion | Beiträge) 10:49, 14. Okt. 2009 (CEST)) [Beantworten]

meinst du das zweite beispiel? wenn ja, was meinst du mit kopplung? angenommen du meinst, daß der klon seinen prototypen kennt, was ist daran falsch? -- 17:40, 14. Okt. 2009 (CEST)[Beantworten]

Vor und Nachteile[Quelltext bearbeiten]

"Viele Optimierungen ... lassen sich aufgrund der dynamischen Natur von prototypen-basierten Sprachen bei diesen nicht realisieren."

Wo ist der Beleg für den Nachteil? Alle Optimierungen statischer oder klassenbasierter Sprachen sind möglich wenn und weil die konkreten Typen der Ein- und Ausgangsparameter bekannt sind. Das ist unabhängig von dynamisch oder statisch. Erfolgen die sowieso notwendigen Prüfungen von Eingaben und sind die Typen der Datensenken und Primitives (eingebaute Funktionen) bekannt, dann sind die Typen an jeder Programmstelle bekannt. Folglich kann dann (nahezu) identisch zu statischen Sprachen optimiert werden. Dynamische Sprachen tun das typischerweise zur Laufzeit (JIT-Compiler).

Wahr ist, das die Optimierung schwieriger ist weil die möglicherweise sehr vielen Typen an der Optimierungsstelle erst herausgefunden werden müssen. Manchmal ist das sehr schwer - statische Sprachen behelfen sich hier mit dynamic_cast, void* usw. wo ebenfalls kaum klassisch zu optimieren ist.

Siehe die Arbeiten von Ole Agesen, z.B. Type Inference of SELF, Analysis of Objects with Dynamic and Multiple Inheritance Software - Practice & Experience, 25(9):975-995, September 1995. -- (jb) 91.57.175.103 18:04, 19. Jan. 2012 (CET)[Beantworten]

eine sprache, die dynamic_cast, void* usw. unterstützt ist aber auch nicht mehr (vollständig) statisch. -- 00:35, 22. Jun. 2012 (CEST)[Beantworten]

Bitte Überarbeiten - Beispiel ist unverständlich für diejenigen, die JavaScript noch nicht kennen[Quelltext bearbeiten]

Erster Beispielcode, die erste Zeile ist noch einfach. Bei der zweiten scheint eine neue vom Objekt1 unabhängige Funktion Namens child() definiert zu werden. Auf welches Objekt mit dem this Zeiger innerhalb child() zugegriffen wird, ist aber unklar. Denn child() wird als Parameter kein Objekt übergeben, wie man es z.B. in Java oder C++ erwarten würde und child() selbst ist ja keine Methode von Objekt1. Dann geht es weiter, die nächste Anweisung ist völlig unklar. Denn was ist child.prototype? Wäre prototype eine Methode, dann müßte das irgendwo definiert sein, gleiches gilt für child, was hier nun plötzlich ein Objekt zu sein scheint, dabei wurde im Beispielcode bisher doch nur eine freie Funktion definiert und kein Objekt Namens child. Auch kann man nicht sagen, daß hier ein neues Objekt Namens child.prototype erzeugt und gleich mit dem Objekt1 initialisiert wird, denn dafür fehlt ja vor child.prototype der Bezeichner var. In der nächsten Zeile wird dann objekt2 erzeugt und als Konstruktor child() aufgerufen. Da hier nun mit this das eigene Objekt gemeint ist, also objekt2 ist wenigstens das noch nachvollziehbar. Die zwei letzten Befehle sind verständlich, sofern man weiß, daß alert() eine Javascript Funktion ist, die im Browser ein Hinweisfenster öffnet. Allem in allem ist die Erklärung aber sehr schlecht und besonders Leute mit Java und C++ Erfahrung (so wie auch ich) dürften sich hier schwer tun, wenn sie noch nie mit Javascript gearbeitet haben. Vorschlag¡ Es wäre nett, wenn jemand zu jeder Zeile im Code ein Kommentar am Ende anfügt, in der dann eindeutig geklärt wird, was diese Anweisung genau macht. Danke. So ist das jedenfalls für einen WP Artikel noch nicht zu gebrauchen. --84.58.219.185 13:56, 20. Jun. 2012 (CEST)[Beantworten]

Das ist ja auch ein Artikel über prototypenbasierte Programmierung und kein Tutorial. Die Beispiele dienen lediglich der Veranschaulichung, wie das in einzelnen Sprachen umgesetzt wurde und dienen auf keinen Fall dazu, jeden Aspekt der jeweiligen Umsetzung zu beleuchten. Falls du mehr über PP lernen willst, gibt es zahlreiche gute Tutorials (hier sogar ein deutschsprachiges, dass das Beispiel sogar in ähnlicher Form behandelt).
Dir steht es aber natürlich auch frei, den Artikel zu verbessern. Ich persönlich sehe daran aber aktuell keinen Grund -- Nachtgestalt Licht aus! 23:25, 21. Jun. 2012 (CEST)[Beantworten]
Das Beispiel sollte anhand von Pseudocode erklärt werden können und dabei auch verständlich sein, ohne das der Leser erst noch JavaScript lernen muss. Dies ist momentan nicht der Fall. Man kann hier nicht erwarten, erst noch eine neue Programmiersprache zu lernen um dieses Programmierparadigma zu verstehen. Hier in diesem Artikel habe ich mal vorgemacht, wie man zu einem Artikel bezüglich dem Thema Programmierung ein ordentliches Beispiel macht, so sollte ein ordentliches Beispiel sein. Dieses Beispiel wurde von mir damals verbessert, weil es zu Beginn auch sehr schlecht war, so sollte das aussehen. Das kann nun jeder verstehen, das könntet ihr euch für diesen Artikel hier als Vorbild und Beispiel nehmen wie man so etwas macht. --84.58.219.185 00:25, 22. Jun. 2012 (CEST)[Beantworten]
Wozu ist das Beispiel eigentlich da, wenn es die Thematik gar nicht veranschaulichen kann und man auf einen externen Link verwiesen wird, um es dort dann verstehen zu können? Irgendwie gibt das keinen Sinn. Ich schlage vor das Beispiel zu verbessern oder ganz zu entfernen, wer dann Beispiele braucht, der kann ja dann den angegebenen externen Link aufsuchen. --84.58.218.47 00:43, 22. Jun. 2012 (CEST)[Beantworten]

Drei (geringfügig) unterschiedliche Beispiele scheinen mir für Laien sinnlos, und wer Java kann, braucht unseren Artikel sowieso nicht.

Ich würde 1. u. 3. Beispiel werfen, dafür das 2. zeilenweise kommentieren. Da ich aber keine Lust habe, am nächsten Baum aufgeknüpft zu werden, versuche ich vorher Meinungen einzuholen. --RobTorgel (Diskussion) 14:38, 27. Jul. 2012 (CEST)[Beantworten]

wer java kann, kann noch lange kein javascript... -- 18:09, 27. Jul. 2012 (CEST)[Beantworten]
Eben, und vielleicht kann er sogar beides nicht. WIe gesagt, ich will nur keinen EW entfesseln, wenn ich die Beispiel eindampfe --RobTorgel (Diskussion) 19:12, 27. Jul. 2012 (CEST)[Beantworten]

Das Beispiel ist mMn falsch; in jedem Falle aber irreführend. Denn das, was dort mit Klonen bezeichnet wird, ist eben _kein_ Klonen. Die Funktion Object.create(a) klont kein Object, sie erstellt lediglich ein neues Object, das a als Prototypen erhält:

var myObj = { a: "a text" }; var anotherObj = Object.create(myObj);

Es gilt nun: anotherObj.__proto__ == myObj // true. ABER: anotherObj ist strenggenommen KEIN Klon von myObj, denn die Attribute unterscheiden sich:

myObj.hasOwnProperty(a) // true anotherObj.hasOwnProperty(a) // false!

Um zu verstehen, wo der Unterschied liegt, muss man wissen, wie JavaScript properties auf Objects auflöst. Dadurch, dass anotherObj eben als Prototyp myObj hat, kann ich anotherObj aufrufen und bekomme denselben Wert.

Insbesondere sieht man, dass anotherObj eben KEIN Klon ist, wenn man sich das folgende ausführt:

myObj.a = "Got ya!"; console.log(anotherObj.a); // Got ya!

Dies könnte nicht passieren, wenn anotherObj ein Klon von myObj wäre. (nicht signierter Beitrag von 85.115.56.180 (Diskussion) 16:27, 17. Jan. 2018 (CET))[Beantworten]