Diskussion:Prototypenbasierte Programmierung

message: 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)
replies: text: 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)

message: "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)
replies: text: eine sprache, die dynamic_cast, void* usw. unterstützt ist aber auch nicht mehr (vollständig) statisch. -- ∂ 00:35, 22. Jun. 2012 (CEST)
thread_title:  Vor und Nachteile 

message: 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)
replies: text: wer java kann, kann noch lange kein javascript... -- ∂ 18:09, 27. Jul. 2012 (CEST)
replies: text: 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)
thread_title:  Beispiele 

message: 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)
thread_title:  Beispiel