Schrift
[thread]11513[/thread]

Ein paar Programmiertricks (Seite 3)

Leser: 1


<< |< 1 2 3 4 >| >> 40 Einträge, 4 Seiten
KurtZ
 2008-03-24 14:53
#107426 #107426
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
murphy+2008-03-24 06:01:22--
KurtZ+2008-03-23 20:53:21--
[...] Und da die Terminologie von OOP für mich ziemlich inkoherent ist (manche bezeichnen z.B. mit "Objekte" die "Instanzen" andere die "Klassen") und diverse quasistandards einander beißen (smalltalk, Java, ...) würde mich doch interessieren wo du diese spezielle Definition für "Klasse" herholst. [...]


Hmm, einen offiziellen Standard gibt's dafür wohl nicht. Ich bin aber einfach mal davon ausgegangen, dass der Begriff Klasse recht einheitlich im Sinne von "Kombination aus Datenstruktur und Methoden" verwendet wird – jedenfalls ist das die Bedeutung wie sie in der Wikipedia steht ....
Wenn Du anmerkst, dass zum Beispiel die Terminologien von Java und Smalltalk unterschiedlich sind, so ist das eigentlich auch kein Wunder, denn Java gehört zur klassenbasierten Familie objektorientierter Sprachen und Smalltalk zur prototypenbasierten.


Tatsächlich? meine Recherche dazu zählt Smalltalk nicht zu den Prototypischen.
WP-> Smalltalk Programmiersprache

murphy+2008-03-24 06:01:22--
Dass irgendwo Klassen Objekte genannt werden, habe ich eigentlich noch nie gesehen. ... Weißt Du noch, wo Dir diese andere Bezeichnungsweise begegnet ist?


nein, ich habe mich anfang der 90er jahrelang nur theoretisch damit befasst und mir damals für meinen 68000er Assembler ein OO Macropacket gestrickt um Kapselung und Vererbung umzusetzen. Die Literatur von damals ist leider nicht reproduzierbar, da IT-Terminologie von Modeströmungen bestimmt wird.[+4]

Es ist mittlerweile üblich prototypische OO als "Classless" zu bezeichnen. aber die Leute die solche Kriterien herausarbeiten arbeiten IMHO vorwiegend mit statischen Compilersprachen, z.B. kann ich in Perl sehr wohl eine Klasse während der Laufzeit manipulieren ("kann" ne "sollte" !). Auch sind viele Design Patterns in Perl überflüssig.

Mein Verständnis ist das ein "Objekt" eine Struktur ist die Daten und Methoden kaspelt. [3]
Eine "Klasse" ist zum einen eine Menge von Objekten die sich aus der Konstruktion aus einem Vorlageobjekt ergeben zum anderen die Bezeichnung des Vorlageobjekts (als Repräsentanten o. Erzeuger der Klasse).
Die einzelnen Mitglieder einer Klasse heißen "Exemplare" oder "Instanz" [1]

Das legt bisher alles nicht fest wo Daten und Methoden manipuliert werden können/dürfen und wie Vererbung funktioniert.

In der Mathematik ist es auch durchaus üblich "Klassen" zu schachteln, da kann sehr wohl das Exemplar der einen Oberklasse der Repräsentant (d.h. hier Prototyp,Singletonklasse) einer Unterklasse sein. [2]

M.a.W. Links vom Konstruktor steht die Objektinstanz rechts die Objektklasse, wie z.B. in JS mit a=new Array(1,2,3);

Ich gebe zu dass ich mit dieser allgemeinen Terminologie in der Minderheit bin, aber ich denke die ist sauberer als diese ganzen Überfrachtungen mit Modelldetails die nur in C++ oder Java Sinn machen, um nachträglich Design Patterns einzuführen die diese Schranken wieder kontrolliert aufweichen.

Ich muss mir wohl heutzutage eine neue unverbrauchte Bezeichner ausdenken.

Ciao
Kurt


[1] "Instance" ist engl für Exemplar, "Instanz" ist eine dieser schlampigen Übersetzungen wie z.B. "Netzwerk" )

[2] Randbemerkung: Klassen sind mathematisch AFAIK Mengen die sich nicht selbst enthalten dürfen, z.B. sowas wie die "Menge aller nichtleeren Mengen" würde sonst viele Mathemodelle kaputt machen, deswegen Klassen.

[3] so betrachtet ist auch ein Closure ein Objekt, mit z.B.
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
sub new_closure {
  my %self=@_; # initdata
  $self{methode1} = sub {
          my ($para1)=@_;
          return "$para1 $self{data1}";
  };
  return \%self;
}  
$inst=new_closure(
           data1 =>"value 1",
       );

print $inst->{methode1}("GET: ");

baue ich das JS-Modell schon recht gut nach.

NACHTRAG:
[4] AFAIR ... meine erste Begegnung war ein Artikel über Schiffssimulationen mit Simula. Kann auch sein dass irgendwo das Wort "Klasse" gar nicht fiel sondern nur sowas wie "Objekt Auto mit Exemplar Corsa" ...
TMTOWTDYOG (there's more than one way to dig your own grave)
murphy
 2008-03-24 16:22
#107428 #107428
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
KurtZ+2008-03-24 13:53:11--
[...] Tatsächlich? meine Recherche dazu zählt Smalltalk nicht zu den Prototypischen. [...]


Da hast Du wohl recht. Da sich meine Smalltalkerfahrung auf zwei Tage herumspielen mit Squeak beschränkt, wo zumindest ein Teil der Bibliothek einen prototypenbasierten Ansatz verfolgt, habe ich das durcheinander gebracht. Tut mir leid.

Quote
[...] Es ist mittlerweile üblich prototypische OO als "Classless" zu bezeichnen. aber die Leute die solche Kriterien herausarbeiten arbeiten IMHO vorwiegend mit statischen Compilersprachen, z.B. kann ich in Perl sehr wohl eine Klasse während der Laufzeit manipulieren ("kann" ne "sollte" !). Auch sind viele Design Patterns in Perl überflüssig. [...]


Dass man heute durch die Große Verbreitung von Java und Konsorten einen etwas gefärbten Blickwinkel auf Objektorientierung hat, sehe ich auch so. Und dass das Objektmodell, wie man es von Java kennt, der Weisheit letzter Schluss ist, würde ich auch bestreiten ;-)

Was Du über die Veränderbarkeit des Codes zur Laufzeit schreibst ist für mich aber eigentlich ein Merkmal einer dynamischen Sprache und weniger eine Eigenschaft des Objektmodells. Den Unterschied zwischen dem klassen- und dem prototypenbasierten Ansatz würde ich hier darin sehen, dass man zum Beispiel in Perl zwar die Methoden eines Paketes zur Laufzeit verändern kann, damit dann aber gleich alle Objekte verändert, die mit dem Paket geblesst wurden, während man in JavaScript auch lokal für ein einzelnes Objekt die Methoden ändern kann.

Die Grenze wird jedoch verwischt, sobald eine Sprache auch Methoden auf Singletontypen definieren kann (wie z.B. Dylan) oder wenn man einfach Closures oder Funktionspointer in einer Instanzvariablen speichert.

Quote
Mein Verständnis ist das ein "Objekt" eine Struktur ist die Daten und Methoden kaspelt. [3]
Eine "Klasse" ist zum einen eine Menge von Objekten die sich aus der Konstruktion aus einem Vorlageobjekt ergeben zum anderen die Bezeichnung des Vorlageobjekts (als Repräsentanten o. Erzeuger der Klasse).
Die einzelnen Mitglieder einer Klasse heißen "Exemplare" oder "Instanz" [1]


Bei dieser Betrachtungsweise würde ich sagen, der wesentliche Unterschied zwischen einem klassen- und einem prototypenbasierten Ansatz ist der folgende: Ein klassenbasiertes Objektsystem repräsentiert die Mengen von Objekten selbst explizit als Objekte, nämlich als Klassen, und speichert meist in jedem Objekt, das Element solch einer Menge ist, eine Referenz auf die Menge. Ein prototypenbasiertes Objektsystem hingegen fasst die Mengen von Objekten als Äquivalenzklassen auf, die implizit durch einen ihrer Repräsentanten beschrieben werden können, weshalb jedes Objekt, das Element solch einer Menge ist, eine Referenz auf irgendeinen Repräsentanten der mengentypischen Eigenschaften hat, den Prototypen, welcher aber nicht eindeutig bestimmt sein muss, da eine eindeutige Repräsentation der Menge selbst nicht existiert.

Quote
[...] In der Mathematik ist es auch durchaus üblich "Klassen" zu schachteln, da kann sehr wohl das Exemplar der einen Oberklasse der Repräsentant (d.h. hier Prototyp,Singletonklasse) einer Unterklasse sein. [...] Randbemerkung: Klassen sind mathematisch AFAIK Mengen die sich nicht selbst enthalten dürfen, z.B. sowas wie die "Menge aller nichtleeren Mengen" würde sonst viele Mathemodelle kaputt machen, deswegen Klassen. [...]


Also meines Wissens ist das etwas anders: In der klassischen Mengenlehre ist eine Klasse jedes Objekt dass durch ein beliebiges Prädikat auf seinen Elementen definiert ist. Insbesondere kann sich eine Klasse auch ohne weiteres selbst enthalten. Mengen hingegen sind Klassen, die zusätzlich die Zermelo-Fraenkel-Axiome erfüllen. Mengen können sich trotzdem selbst enthalten, aber bei bestimmten komischen Konstruktionen der Art "die Klasse aller Mengen, die xyz erfüllen" kommen eben keine Mengen, sondern echte Klassen heraus. Beispiele für solche echten Klassen sind die Klasse aller Mengen, die sich nicht selbst enthalten, oder die Klasse aller Mengen, die genau sich selbst enthalten.

Da eine Klasse aber praktisch keine Voraussetzungen erfüllen muss, kann bzw. darf man über die Eigenschaften einer echten Klasse im Allgemeinen wenig aussagen :-)
When C++ is your hammer, every problem looks like your thumb.
KurtZ
 2008-03-24 17:14
#107429 #107429
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
murphy+2008-03-24 15:22:50--
Also meines Wissens ist das etwas anders: In der klassischen Mengenlehre ist eine Klasse jedes Objekt dass durch ein beliebiges Prädikat auf seinen Elementen definiert ist. Insbesondere kann sich eine Klasse auch ohne weiteres selbst enthalten. Mengen hingegen sind Klassen, die zusätzlich die Zermelo-Fraenkel-Axiome erfüllen. Mengen können sich trotzdem selbst enthalten, aber bei bestimmten komischen Konstruktionen der Art "die Klasse aller Mengen, die xyz erfüllen" kommen eben keine Mengen, sondern echte Klassen heraus. Beispiele für solche echten Klassen sind die Klasse aller Mengen, die sich nicht selbst enthalten, oder die Klasse aller Mengen, die genau sich selbst enthalten.

Da eine Klasse aber praktisch keine Voraussetzungen erfüllen muss, kann bzw. darf man über die Eigenschaften einer echten Klasse im Allgemeinen wenig aussagen :-)


Ja da hab ich vielleicht was aus der Erinnerung falsch zusammengebracht "Die Klasse aller Mengen, die sich nicht selbst als Element enthalten, die sogenannte Russellsche Klasse" ist ein schönes Beispiel wo Menge statt Klasse versagt. (Die Menge wäre sonst paradoxerweise in sich enthalten und doch auch nicht)

Whatever ... in meinem Verständnis von OOP ist wohl Äquivalenzklasse der eigentliche Terminus und der "gleiche" Konstruktor die Äquivalenzrelation.
TMTOWTDYOG (there's more than one way to dig your own grave)
KurtZ
 2008-03-25 02:15
#107434 #107434
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
murphy+2008-03-23 20:03:48--
Das ist schlicht falsch. ECMA-262 konformes JavaScript kennt das Konzept einer Klasse im Sinne der objektorientierten Programmierung nicht. In dem gesamten Text des Standarddokumentes taucht dieses Konzept kein einziges Mal auf.


Fundsache bei Mozillahttp://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/object.html

prototype
Represents the prototype for this class. You can use the prototype to add properties or methods to all instances of a class. For more information, see Function.prototype.
TMTOWTDYOG (there's more than one way to dig your own grave)
murphy
 2008-03-25 17:18
#107466 #107466
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
KurtZ+2008-03-25 01:15:05--
Fundsache bei Mozilla [...]
prototype
Represents the prototype for this class.
[...]


Trotzdem ist die Klasse hier kein explizites Objekt sondern wird eben nur durch einen Repräsentanten implizit definiert. Da das nicht nur philosophische Auswirkungen hat, sondern auch technische, ist für mich die Unterscheidung relevant.

Außerdem ist diese Bezeichnungsweise nicht aus dem ECMA-262 Dokument sondern auf dem Mist von den Mozillaentwicklern gewachsen.

@KurtZ: Von mir aus kann man vor diesem Hintergrund auch von Klassen in JavaScript sprechen, aber wenn man das tut ohne zu erwähnen wie es gemeint ist, erweckt man bei mir das Gefühl nicht verstanden zu haben, wie die Objektorientierung bei JavaScript funktioniert – um so mehr, da ich schon genügend Leuten begegnet bin, die wegen der weiten Verbreitung anderer Objektsysteme, davon ausgegangen sind, dass es in JavaScript ganz genauso sein müsste, und damit früher oder später auf die Nase gefallen sind. Inzwischen bin ich allerdings überzeugt, dass wir beide das eigentlich schon verstanden haben, aber mit leicht verschiedener Terminologie sehr gut aneinander vorbeireden können ;-)
When C++ is your hammer, every problem looks like your thumb.
KurtZ
 2008-03-25 22:10
#107485 #107485
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
HI Murphy,

hab mich jetzt tiefer in JS-prototyping praktisch eingearbeitet und mich auch belehren lassen und IMHO verwischen die Unterschiede immer mehr -> http://forum.de.selfhtml.org/?t=168754&m=1101416

Auch in den O'Reilly JS-Büchern in denen ich geschmökert habe ist von "Klassen" in Anführungsstrichen und mit Fussnote die Rede.

Man kann die Konstruktorobjekte (also "Klassendefinitionen") von den zugehörigen Instanzobjekten auch gut unterscheiden, erstere haben ein Objektattribut "prototype" mit den "Klassenmethoden" und "Klassenattributen" letztere ein Refrenzattribut "__proto__" das auf den prototype des Konstruktors verweist.

Auch visuell kann man "Instanzobjekte" von "Klassenobjekten" unterscheiden, eine Instanz wird direkt konstruiert
Code: (dl )
  Instanz = new Klasse1(); 


ein Klassenobjekt wird als Funktion deklariert und kann höchstens erben:
Code: (dl )
  Klasse1.prototype= new Klasse0(); 


das folgende erzeugt aber ne Fehlermeldung
Code: (dl )
  Unterinstanz=new Instanz(); // Fehler: Instanz is not a constructor 


Sicher Vererbung mit JS-Prototype bietet Möglichkeiten die einfacher Umzusetzen sind als mit Perl-ISA aber auch umgekehrt. Tatsächlich sind beide AFAIK viel flexibler als C++ oder JAVA was wiederum mehr Disziplin und modifizierte Design-Pattern erfordert.

Letztendlich braucht man aber immer (Denk)Muster und eine sprachliche Möglichkeiten diese abzubilden. Das Denken in Klassen ist eines dieser Muster. M.a.W man müsste es so genau Dokumentieren, dass man wiederum mit den üblichen Designpattern argumentieren würde, wie z.B. einen Konstruktor "Klasse blabla" zu nennen oder eine eingeschachtelte Funktion als "privat" zu bezeichnen.

Und nur weil ich z.B. in JS einzelnen Instanzen eigene Methoden geben kann, fallen mir dazu spontan keine Anwendungsfälle/Muster ein! Bräuchte ich sowas in Perl hätten halt die Instanzen ein Hash wo ich Coderefs namentlich ablege, und mittels AUTOLOAD würden diese aufgerufen. Es geht also in beiden Sprachen/Modellen, man braucht sowas aber wirklich selten.

Die oft zitierte Vererbung durch Cloning habe ich übrigens nicht so deutlich gesehen.

Wenn dir jetzt ein Anwendungsfall einfällt Objekte in JS deutlich anders und effizienter zu modellieren, dann wär ich dir für den Hinweis dankbar.

Bye
Kurt
TMTOWTDYOG (there's more than one way to dig your own grave)
murphy
 2008-03-25 23:30
#107486 #107486
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
KurtZ+2008-03-25 21:10:26--
[...] das folgende erzeugt aber ne Fehlermeldung
Code: (dl )
  Unterinstanz=new Instanz(); // Fehler: Instanz is not a constructor 

[...]
Die oft zitierte Vererbung durch Cloning habe ich übrigens nicht so deutlich gesehen.


Das was new automatisch tut, nämlich den Prototypen zu klonen und dann eine Initialisierungsfunktion auszuführen, kann man auch von Hand machen:
Code: (dl )
1
2
3
4
5
6
var o0 = { a: 1, b: 2 };

var o1 = { };
o1.__proto__ = o0;

alert(o1.b);


Schon haben wir einen Klon von o0 erzeugt, ohne dass irgendwelche Klassen im Spiel wären ;-)

Quote
Und nur weil ich z.B. in JS einzelnen Instanzen eigene Methoden geben kann, fallen mir dazu spontan keine Anwendungsfälle/Muster ein! Bräuchte ich sowas in Perl hätten halt die Instanzen ein Hash wo ich Coderefs namentlich ablege, und mittels AUTOLOAD würden diese aufgerufen. Es geht also in beiden Sprachen/Modellen, man braucht sowas aber wirklich selten.


Es geht in den meisten Sprachen, wenngleich sich die Aufrufsyntax dann von der normaler Methoden unterscheidet, aber bei JavaScript ist es die einzige Methode um neue Methoden zu erzeugen.

An einem einzelnen Objekt, das nicht als Prototyp gedacht ist, neue Methoden zu verankern macht aber nur gelegentlich wirklich Sinn. Es kann zum Beispiel nützlich sein, wenn eine Funktion, die man über eine JavaScript<->XPCOM oder JavaScript<->Java Brücke aufruft, als Argument die Instanz eines bestimmten Interfaces erwartet.

Quote
Wenn dir jetzt ein Anwendungsfall einfällt Objekte in JS deutlich anders und effizienter zu modellieren, dann wär ich dir für den Hinweis dankbar.


Nö, da fällt mir nichts ein. Effizient ist JavaScript sowieso meistens nicht und das wird es auch nicht dadurch, dass man kompliziertere Konstruktionen baut ;-)
When C++ is your hammer, every problem looks like your thumb.
KurtZ
 2008-03-26 00:56
#107487 #107487
User since
2007-12-13
411 Artikel
BenutzerIn
[default_avatar]
murphy+2008-03-25 22:30:22--
Das was new automatisch tut, nämlich den Prototypen zu klonen und dann eine Initialisierungsfunktion auszuführen, kann man auch von Hand machen:
Code: (dl )
1
2
3
4
5
6
var o0 = { a: 1, b: 2 };

var o1 = { };
o1.__proto__ = o0;

alert(o1.b);


Schon haben wir einen Klon von o0 erzeugt, ohne dass irgendwelche Klassen im Spiel wären ;-)


hmm dann haben wir unterschiedliche Vorstellungen von Klonen, in "perlisch" gesprochen ist o1.__proto__ eine Referenz auf o0. Klonen wäre für mich eine 1 zu 1 Kopie des Objektes, also in Perl eine Kopie der Hashes, %o1=%o0. (aber ich seh gerade dass müsste der unterschied zw. Shallow und Deep Cloning sein)

Bin übrigens darauf hingewiesen worden dass nur Netscape/Mozilla direkten Zugriff auf __proto__ erlauben.

Diese prototypische Vererbung ist schon schick, sowas wie "abstrakte Klassen" müsste sich so sehr einfach realisieren lassen, wenn man Klassen so einfach generiert wie Objekte.

Und wenn sowohl Vererbung als auch Instanzierung über die gleichen "new"-Semantik läuft ist die Komplexität geringer und es müsste auch simpler zu begreifen sein.

Es gibt übrigens auch ein "Prototype Pattern" wo viel geklont wird, vielleicht taucht deswegen die Begrifflichkeit so oft auf.

Naja genug philosophiert ist schließlich ein Perlforum :)

PS: JS ist mir übrigens sympatischer als Python, insbesondere als "embedded language" insbesondere auch weil viele Konzepte bei Perl angelehnt sind.

EDIT .... Man könnte auch alternativ den Begriff Typ statt Klasse nehmen um eine unmissverständliche Begrifflichkeit für beide Modelle zu haben.
TMTOWTDYOG (there's more than one way to dig your own grave)
Struppi
 2008-03-26 10:40
#107492 #107492
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
KurtZ+2008-03-25 21:10:26--
Man kann die Konstruktorobjekte (also "Klassendefinitionen") von den zugehörigen Instanzobjekten auch gut unterscheiden, erstere haben ein Objektattribut "prototype" mit den "Klassenmethoden" und "Klassenattributen" letztere ein Refrenzattribut "__proto__" das auf den prototype des Konstruktors verweist.

Aber denk daran, nur Mozilla Browsern habe darauf der Zugriff (Mathias Ergänzung im selfhtml Forum)

[EDIT]hab dein letztes Posting nicht gelesen.

KurtZ+2008-03-25 21:10:26--
ein Klassenobjekt wird als Funktion deklariert und kann höchstens erben:
Code: (dl )
  Klasse1.prototype= new Klasse0(); 


das folgende erzeugt aber ne Fehlermeldung
Code: (dl )
  Unterinstanz=new Instanz(); // Fehler: Instanz is not a constructor 


Deine erste Erläuterung verstehe ich nicht. Da es keine Klassen gibt, gibt es auch kein Klassenobjekt, jede Funktion ist erstmal per se ein Konstruktor und du machst dort nominell nichts anderes als dem prototype von Klasse1 mit einer Instanz von Klasse0 zu überschreiben. Du erweiterst also Klasse1 um alle Attribute, die der Konstruktor Klasse0 erzeugt und dessen prototypen. Das war ja auch ursprünglich deine Frage, du kannst diesen Prototype jederzeit überschreiben.
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
  function Klasse0() {this.name = 'Klasse 0';}
function Klasse1() {this.name = 'Klasse 1';}
function Klasse2() {}

Klasse2.prototype= new Klasse0();
var a = new Klasse2();
alert( a.name + '\n' + a.constructor);

Klasse2.prototype= new Klasse1();
var a = new Klasse2();
alert( a.name + '\n' + a.constructor);


Im zweiten Fall könnte man sich noch behelfen in dem man schreibt:

Code: (dl )
  var Unterinstanz=new Instanz.constructor(); 


KurtZ+2008-03-25 21:10:26--
Sicher Vererbung mit JS-Prototype bietet Möglichkeiten die einfacher Umzusetzen sind als mit Perl-ISA aber auch umgekehrt. Tatsächlich sind beide AFAIK viel flexibler als C++ oder JAVA was wiederum mehr Disziplin und modifizierte Design-Pattern erfordert.


Das sehe ich anders, Vererbung ist mit JS umständlich, einmal hast du keinen direkten Zugriff auf SUPER und zum zweiten wird durch new BasisKlasse() immer eine Instanz der Basis Klasse erzeugt, was zur Folge hat, das der Konstruktor aufgerufen wird und du dort aufpassen musst, wenn du eine für jede Instanz unterschiedliche Initialisierung machen willst, das geht in die Hose. Du musst entweder die Intialisierung in eine Funktion verlagern oder den Weg, den dir Don P im selfhtml Forum gezeigt hat wählen.
murphy
 2008-03-27 02:11
#107525 #107525
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
KurtZ+2008-03-25 23:56:28--
hmm dann haben wir unterschiedliche Vorstellungen von Klonen, in "perlisch" gesprochen ist o1.__proto__ eine Referenz auf o0. Klonen wäre für mich eine 1 zu 1 Kopie des Objektes, also in Perl eine Kopie der Hashes, %o1=%o0. [...]


Naja, das neue Objekt ist konzeptionell schon eine Kopie des alten, denn sämtliche Eigenschaften und Methoden des alten Objektes sind auch im neuen sichtbar. Dass die Eigenschaften nicht wirklich kopiert, sondern nur eine Verknüpfung auf das Originalobjekt gesetzt wird, ist zum einen effizienter als eine volle Kopie anzufertigen und zum anderen hat es, wie man's nimmt, den zusätzlichen Vor- oder Nachteil, dass nachträgliche Änderungen am Original sich auf die Kopie auswirken können.

Quote
Bin übrigens darauf hingewiesen worden dass nur Netscape/Mozilla direkten Zugriff auf __proto__ erlauben.


Das war mir auch bewusst. Aber nachdem es jetzt leider aufgefallen ist, muss ich wohl doch noch die standardkonforme Variante der clone-Methode nachreichen ;-)

Code: (dl )
1
2
3
4
5
6
7
8
9
10
Object.prototype.clone = function () {
var CloneConstructor = function () { }
CloneConstructor.prototype = this
return new CloneConstructor()
}

var o0 = { a: 1, b: 2 }

var o1 = o0.clone()
alert(o1.b)


Die Funktion sieht halt etwas abstrus aus, ist aber leicht zu verwenden und auch noch ein gutes Beispiel für die Veränderung eines existierenden Prototypen ;-)
When C++ is your hammer, every problem looks like your thumb.
<< |< 1 2 3 4 >| >> 40 Einträge, 4 Seiten



View all threads created 2008-03-22 23:16.