1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
Erkenntnisse aus sj/sj1, die in sj2 beachtet werden mssen
- Call von C++
"javascript: ..." nicht wie event behandeln, insbesondere werden
this und document nicht implizit als Search-Objekte gesetzt.
- prototype Eigenschaft von Objekten:
Manipuliert Klassen-Informationen, falls an einem beliebigen Objekt
eine Property mit gleichem Namen angelegt wird, so gilt dieses
Ueberschreiben jedoch nur fuer dieses eine Objekt !!!
Im Sj/Sj1 Projekt ist dies jedoch nicht erfuellt !
Beispiel:
function Ctor() { ... }
obj1 = new Ctor(); // obj1 obj2
obj2 = new Ctor(); //-------------------------
Ctor.prototype.toString = myToString; // myToString myToString
obj1.toString = myToString2; // myToString2 myToString
Ctor.prototype.toString = myToString3; // myToString2 myToString3
- toString() und valueOf() Behandlung des BaseObj bei Type-Konversion
========================================================================
Bemerkungen zur Suchreihenfolge und zum Ueberladen von Funktionen:
* fuer jede 'Klasse' (z.B. Math, Date, String) gibt es ein Konstruktor-
Objekt in der JavaScript-Umgebung.
In dem Konstruktor-Objekt werden die Properties der Klasse angelegt,
z.B. sin, cos.
Der Konstruktor setzt seine Properties an jedem neu erzeugten
Objekt. Daher hat z.B. jedes Date-Objekt eine (default-behandelte)
Property setMonth.
Zum Setzten der Properties des Konstruktor an das neu erzeugte
Objekt sollte die initProp()-Methode noch einen Bereich der zu
kopierenden Properties bekommen, damit nicht alle nachtraeglich
am Konstruktor-Objekt angelegten Properties auch am Objekt gesetzt
werden.
* jedes Objekt haelt eine Referenz auf seinen Konstruktor (entweder die
vordefinierten Klassen wie Math, Date oder die Funktion mit der das
Objekt erzeugt wurde).
* fuer die Suchreihenfolge gibt es folgende drei Moeglichkeiten:
- Default-behandelte Property:
aStrg = new String( "gulp" );
aStrg.toString() // --> verwendet toString-Property am
// String-Konstruktor (default-Behandlung)
- Default-Behandlung ueberladen am Konstruktor:
aStrg = new String( "gulp" );
String.prototype.toString = myToString; // UEBERLADEN !
aStrg.toString() // --> verwendet myToString-Funktion.
// Das prototype-Objekt wird am String-Ctor.
// angelegt und ueberschreibt daher die
// default-behandelte Property am Objekt !!!
// Der Interpreter muss dann noch an einem
// ggf. vorhandenen prototype-Objekt am
// Konstruktor nach der Property suchen.
- ueberladen am Objekt:
aStrg = new String( "gulp" );
String.prototype.toString = myToString; // am Ctor. ueberladen
aStrg.toString = myToString2;
aStrg.toString() // --> verwendet myToString2-Funktion.
// Die Property toString wird am Objekt
// ueberschrieben und somit das Flag, dass
// die default-Behandlung anzeigt, zurueck
// gesetzt. D.h. der Interpreter muss das
// prototype-Objekt des Konstruktors NICHT
// durchsuchen.
========================================================================
DEMNAECHST:
Die Properties der Standard-Objekte (z.B. setSeconds() am Date)
werden am prototype-Objekt des Konstruktors (z.B. DateCtor) angelegt.
Bei der Suche nach Properties an einem beliebigen Objekt wird erst
das Objekt durchsucht und anschliessend das prototype-Objekt des
Konstruktors fuer das Objekt durchsucht. Dieses Verhalten gleicht
dem Netscape-Verhalten (Stand 2.7.1997).
ACHTUNG, AB 11.8:
Das ist so nicht korrekt, da die entsprechenden Properties direkt
am prototype-Objekt nicht bekannt sind. Die an den Objekten als
Default geflagten Properties bilden daher das Netscape-Verhalten
besser ab.
========================================================================
WEITERE OFFENE PROBLEME:
------------------------
* this auf der Wiese funktioniert noch nicht korrekt
* Konversion von Typen ?
|
