vererbung / delegationsprinzipien

[peterS.]

hallo again Felix,

bitte entschuldige die lange wartezeit - ich bin gerade vielbeschaeftigt.

... die eigentliche Haupt-Klasse (in seinem beispiel cnstr) ... ««

[cnstr] ist eine konstruktor-funktion. JavaScript ist klassenlos!

Ja, für mich steht ein Konstruktor als synonym für eine klasse.

trenn Dich im kontext von JavaScript von dieser *denke*.

Wie könnte ich sonst Konkrete Objekte (per "new") erzeugen ohne
eine art "Klasse". :)

auch in klassenbasierte oo benoetigst Du dazu nur den konstruktor ;-)

...Das kam weil ich die Bedeutung des Call-Operators mit der call()-
methode verwechselt hatte, welche ja ein neues objekt "konstruiert",
wobei der operator nur "aufruft" ...

noe ... call-operator »()« und die call methoden »apply« und »call«
haben grundsaetzlich erstmal die gleiche aufgabe, naemlich ein
funktionsobjekt auszufuehren. ueber die beiden call-methoden lassen
sich ausserdem noch auf unterschiedlich flexible weise argumente an
eine funktion verbacken. darueber hinaus, und das ist der bei weitem
wichtigste aspekt, laesst sich der kontext, in welchem eine methode
ausgefuehrt werden soll, manipulieren.

die lokalen variablen einer funktion sind von ausserhalb dieses sie
einschliessenden adressraumes nicht adressierbar. werden  funktionen
nur geschickt genug verschachtelt, koennen sich deren lokale variablen,
obwohl von aussen immer noch nicht zugaenglich, trotzdem durch die
adressraeume hindurch referenzieren. und ... solange referenzen von
noch *lebenden* objekten in eine eigentlich schon abgearbeitete
funktion hinein bestehen, wird diese nicht von der automatischen

--------------------------------^^^^^^^^^^
da muss ich mich korrigieren:
                                werden diese nicht von der automatischen

speicherbereinigung (garbage collection) erfasst.

Also kann man durch kaskadieren von funktionen verschiedene
Sichtbarkeitsbenen von variablen erzeugen, die sich durch referenzieren
zum teil umgehen lassen...

so liesse sich das formulieren ... ja.

die ueber [[Function]] referenzierten methoden [apply] und [call]
ermoeglichen es einem objekt, die methoden eines anderen objekts zu
*borgen* und im eigenen kontext auszufuehren, ohne diese methoden
selbst besitzen zu muessen.

angenommen ich arbeite mit call, und ich überschreibe eine Funktion
der "Klasse" die ich über call konstruiere, wie kann ich dann noch
auf sie zugreifen? zb:

function SuperCat() {
  this.sound = "miaow";
}

function SubCat() {

SuperCat.call(this);

/*
  sehr gut, dass kommt einem klassenbasierten »super()« so nahe wie
  moeglich.
  dieses muster, einen weiteren konstruktor im kontext eines gerade
  durch einen anderen konstruktor im instanziierungsprozess befindlichen
  objekts aufzurufen, benutze ich als delegations-pattern fuer interfaces.
*/

var instance = this;
  this.sound ="overridden miaow";

/*
  das war es dann aber auch schon. das ueber »super()« implementierte
  [[SuperCat]]-[sound] wird jetzt explizit ueberschrieben.
*/

this.makesound = function() {
    alert("the cat says" + instance.sound);
  }
}

var felixcat = new SubCat();
felixcat.makesound();

wie rufe ich den member "sound" von der mit call erzeugten instanz
der "Klasse" SuperCat auf? Ich meine wie referenziere ich diesen?
geht das überhaupt?

ja. statt des emulierten »super()« liesse sich eine [[SuperCat]]-
instanz zum prototypen eines [[SubCat]]-konstruktors bestimmen:

var SuperCat = (function () {  
  
  this.sound = "miaow";  
});  
  
var SubCat = (function () {  
  
  alert("this.constructor : " + this.constructor); // [[SuperCat]]  
  
  this.constructor = arguments.callee; // [prototype]-referenz ueberschreiben  
  
  alert("this.constructor : " + this.constructor); // [[SubCat]]  
  
  this.sound ="meow";  
  
  this.makeSound = (function () {  
  
    alert("the cat says \"" + this.sound + "\"");  
  });  
  this.makeProtoSound = (function () { // makeSuperSound  
  
    alert("the cat says \"" + this.constructor.prototype.sound + "\"");  
  });  
});  
SubCat.prototype = new SuperCat();  
  
var felixcat = new SubCat();  
  
felixcat.makeSound(); // "meow"  
felixcat.makeProtoSound(); // "miaow"

in JavaScript waere man deshalb geradezu dazu verpflichtet,
objektkomposition auf basis wohldefinierter schnittstellen
als nativen - weil durch das sprachkonzept vorgegebenen -
vererbungsmechanismus direkt einzusetzen, statt zu versuchen,
klassenvererbung auf den gerade genannten grundlagen zu emulieren.

Naja damit muss ich mich noch anfreunden...

beispiel zum anfreunden ...

gibt es dagegen eher das problem, dass nur [[SuperCat]] ein [makeSound]
zur verfuegung stellt und trotzdem nicht prototyp von [[SubCat]] sein
kann, liesse sich das problem fuer [[SubCat]]-instanzen fogendermassen
aus der welt schaffen:

var SuperCat = (function () {  
  
  this.sound = "miaow";  
});  
SuperCat.prototype.makeSound = (function () {  
  
  alert("the cat says \"" + this.sound + "\"");  
});  
  
var SubCat = (function () {  
  
  this.sound = "";  
});  
  
var felis = new SuperCat();  
felis.sound = "meow meow meow";  
  
var felixcat = new SubCat();  
felixcat.sound = "meow";  
  
alert(felixcat.makeSound); // [undefined]  
felis.makeSound(); // "meow meow meow" - die prototypisch referenzierte methode im kontext von [felis]  
felis.makeSound.call(felixcat); // "meow" - delegierter [felixcat]-kontext auf fuer [felis] erreichbare methoden

Danke für deine Mühe Peter!

nicht dafuer.

so long - peterS. - [e-mail]