Christian S.: Objekte (Literale) erben lassen

Hi,

ich möchte mehreren Objekten, die alle verschieden sind, die gleiche Grundfunktionalität zuweisen.

Dazu habe ich einen Basiskonstruktor geschrieben, der die Grundfunktionalität beinhaltet:

  
function Base()  
{  
   this.set = function()  
   {  
      // tu was  
   };  
   this.reset = function()  
   {  
     // tu auch was  
   };  
}  

Meine Objekte würde ich sehr gerne über ein Literal erzeugen, da jedes meiner Objekte nur einmal existiert und alle unterschiedlich sind! Ich brauche also keinen Konstruktor dafür.

  
var obj1 = {a:1};  
var obj2 = {b:2};  

Wie bekomme ich an diese Objekte nun die Methoden der Base Klasse dran (set und reset) ??

Ich weiß dass ich es auf dem umständlichen Wege über einen Konstruktor und prototype vererben kann:

  
function Obj1Konstruktor()  
{  
   this.a = 1;  
}  
Obj1Konstruktor.prototype = new Base();  
var obj1 = new Obj1Konstruktor();  

Aber genau das möchte ich umgehen, da ich nicht noch jedes mal einen Konstruktor schreiben will (und mir immer noch neue Konstruktornamen ausdenken möchte). Wie gesagt, ich brauche immer nur EINE Instanz. Ein Konstruktor würde immer nur einmal aufgerufen werden, weshalb ich eigentlich keinen benutzen möchte.

Habe schon verschiedenes probiert wie:

  
var obj1 = {prototype:new Base(), a:1};  

aber ging bisher alles nicht.

Hat jemand eine Idee?

Gruß
Christian

  1. Hallo,

    prototype-Eigenschaften haben nur Konstruktorfunktionen. Der Konstruktor eines Object-Objektes ist ... Trommelwirbel ... »Object«. Also könntest du schreiben:

    Object.prototype.set = function () {};

    Das macht das, was du willst, ABER: Das hat SEHR radikale Nebenwirkungen. Weil von Object *alle* Objekte in JavaScript abstammen und du damit *allen* Objekten eine set-Methode gibst. Und diese ist »enumerable«, das heißt, sie kommt dir ständig in die Quere, wenn du irgendwo etwa for (var i in objekt) verwendest.

    Das ist ein extrem schwieriges, viel diskutiertes Feld, Fazit ist eigentlich immer noch Object.prototype is verboten.

    var obj1 = {a:1};

    Musst du halt
    var obj1 = new Base({a:1});
    schreiben und im Konstruktor alle Eigenschaften des Object-Parameters nach this kopieren.

    Aber genau das möchte ich umgehen, da ich nicht noch jedes mal einen Konstruktor schreiben will (und mir immer noch neue Konstruktornamen ausdenken möchte).

    Konstruktoren machen ja auch nur Sinn, wenn du mehrere Objekte davon ableiten willst. (Ok, es gibt auch Singleton-Gedöhns, das mal außen vor.)

    ich möchte mehreren Objekten, die alle verschieden sind, die gleiche Grundfunktionalität zuweisen. (... vs. ...)
    Wie gesagt, ich brauche immer nur EINE Instanz.

    Du sagst ja selbst, dass sich alle manche Methoden/Eigenschaften teilen und andere nicht - das Szenario ist doch prädestiniert für klassisches JavaScript-OOP mit Konstruktoren.

    Mathias

    1. Hi,

      Object.prototype.set = function () {};

      ich glaube ich hatte mal probiert: Object.prototype = new Base();

      aber das ging nicht...

      Musst du halt
      var obj1 = new Base({a:1});
      schreiben und im Konstruktor alle Eigenschaften des Object-Parameters nach this kopieren.

      wäre eine Idee...

      Konstruktoren machen ja auch nur Sinn, wenn du mehrere Objekte davon ableiten willst. (Ok, es gibt auch Singleton-Gedöhns, das mal außen vor.)

      eben, aber ich brauche nur eins...

      ich möchte mehreren Objekten, die alle verschieden sind, die gleiche Grundfunktionalität zuweisen. (... vs. ...)
      Wie gesagt, ich brauche immer nur EINE Instanz.

      Du sagst ja selbst, dass sich alle manche Methoden/Eigenschaften teilen und andere nicht - das Szenario ist doch prädestiniert für klassisches JavaScript-OOP mit Konstruktoren.

      Alle haben die gleiche Grundfunktionalität, ja. Aber die Member die sie sich nicht teilen, sind einzigartig.

      Also alle haben set und reset, aber die Property eines Objekts, die zB xyz123 heißt, gibt es nur in einem einzigen Objekt, sonst in keinem anderen.

      Gruß
      Christian

    2. hallo molily,

      Object.prototype.set = function () {};

      Das macht das, was du willst, ABER: Das hat SEHR radikale Nebenwirkungen.
      ...
      Das ist ein extrem schwieriges, viel diskutiertes Feld, ...

      ... und ich weiss nichteinmal warum.

      ... Fazit ist eigentlich immer noch Object.prototype is verboten.

      eben nicht - warum soll ich die moeglichkeiten der sprache an
         entscheidender stelle beschneiden? wenn es denn doch mal dazu
         kommt, das ein prozess objekte ueber "for ... in" zu iterieren
         hat, dann ist dieser prozess eben so wasserdicht zu schreiben,
         dass das odnungsgemaesse funktionieren weiterer programmlogik
         nicht davon abhaengt, ob an [Object.prototype] rumgeschraubt
         wurde oder nicht, denn fuer die allermeisten faelle, fuer die
         dieses verbot gefordert wurde, laesst sich erkennen, ob gefundene
         eigenschaften dem objekt nun unmittelbar oder eben *nur* ueber
         [prototype]-referenzen *gehoeren*.

      kampfeslustige gruesse - peterS. - pseliger@gmx.net

      --
      »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
      Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
      ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
      1. Hallo,

        wenn es denn doch mal dazu kommt, das ein prozess objekte ueber "for ... in" zu iterieren hat, dann ist dieser prozess eben so wasserdicht zu schreiben (...)

        Klar, wenn man sich Scripts von erfahrenen Programmierern oder größere Frameworks anschaut, so bringen die nicht nur eigene Vererbungsfunktionen mit, sondern sind auch so tolerant gebaut, dass beim for-in nichts schiefgehen kann, auch wenn sie Object.prototype selbst nicht erweitern.

        Das Problem sind wohl eher Scripte, die nicht darauf achten und Programmierer, die nicht ahnen, was es bedeutet, Object-prototype zu erweitern. Heutzutage nutzen Websites viele fremde Scripte, die sich seltenst an gemeinsame Grundlagen halten. Damit die untereinander kompatibel sind und einfach nicht wissen müssen, was andere Scripts prototypisch verbrochen haben, gibts halt diese Praxiskonvention. Die Konvention richtet sich eher an Autoren von wiederverwendbaren Scripten oder Bibliotheken, damit deren Anwender verschiedene und eigene Scripts problemlos einsetzen können. Wer natürlich den Durchblick hat, welcher Code auf der Site zum Einsatz kommt und den ggf. modifiziert, braucht diese Regel nicht unbedingt.

        Mathias

        1. hallo again molily,

          ...
          Heutzutage nutzen Websites viele fremde Scripte, die sich seltenst
          an gemeinsame Grundlagen halten. Damit die untereinander kompatibel
          sind und einfach nicht wissen müssen, was andere Scripts prototypisch
          verbrochen haben, gibts halt diese Praxiskonvention. ...

          welche versucht, dass pferd von hinten aufzuzaeumen - »theorie hin,
             praxis her« - ja ich weiss schon, warum viele das so gahandhabt
             sehen wollen. trotzdem stoer' ich mich immer mal wieder an diesem
             kastrationsversuch.

          ... Die Konvention
          richtet sich eher an Autoren von wiederverwendbaren Scripten oder
          Bibliotheken, damit deren Anwender verschiedene und eigene Scripts
          problemlos einsetzen können. ...

          die ursache dieses (nicht)problems laesst sich uebrigens ganz einfach
             - ironie und staerke des sprachkonzept - *prototypisch* aus der welt
             schaffen ... statt *for ... in* implementiere man einen [Object]-
             objekt-iterator ...

          ~~~javascript Object.prototype.forEachOwnProperty = function () {
               // voilà
             };

            
          
          >                          ... Wer natürlich den Durchblick hat, welcher  
          > Code auf der Site zum Einsatz kommt und den ggf. modifiziert, braucht  
          > diese Regel nicht unbedingt.  
            
             ... und jedermann kann weiterhin nach eigenem gusto entwickeln, ohne  
             von elitaeren sprachhuetern verachtet oder mit abstrakten theoretischen  
             betrachtungen gegaengelt zu werden.  
            
            
            
             by(t)e by(t)e - peterS. - pseliger@gmx.net  
            
            
          
          -- 
          »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.  
          Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - [Douglas Crockford](http://javascript.crockford.com/)  
            
          ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
          
  2. hallo again Christian,

    ... Du haettest ruhig im alten thread weitermachen koennen.
       gewoehnlich werden die von einem OP zur sprache gebrachten
       probleme von den antwort gebenden solange verfolgt und/oder
       betreut, bis der OP und/oder der antwortende schlauer ist -

    so wie ich jetzt auch in Deinem fall:

    ich möchte mehreren Objekten, die alle verschieden sind,
    die gleiche Grundfunktionalität zuweisen.
    Dazu habe ich einen Basiskonstruktor geschrieben, der die
    Grundfunktionalität beinhaltet:

    function Base() {

    ...
    }

    
    >   
    > Meine Objekte würde ich sehr gerne über ein Literal erzeugen,  
    > da jedes meiner Objekte nur einmal existiert und alle  
    > unterschiedlich sind! Ich brauche also keinen Konstruktor dafür.  
    > ...  
    > Wie bekomme ich an diese Objekte nun die Methoden der Base  
    > Klasse dran (set und reset) ??  
    >   
    > Ich weiß dass ich es auf dem umständlichen Wege über einen  
    > Konstruktor und prototype vererben kann:  
    >   
    > ~~~javascript
    
    function Obj1Konstruktor()  
    
    > {  
    >    this.a = 1;  
    > }  
    > Obj1Konstruktor.prototype = new Base();  
    > var obj1 = new Obj1Konstruktor();
    
    

    Aber genau das möchte ich umgehen, da ich nicht noch jedes mal
    einen Konstruktor schreiben will ... Habe schon verschiedenes
    probiert wie:

    var obj1 = {prototype:new Base(), a:1};

    aber ging bisher alles nicht.

    aehm ja, tut mir leid, dass ich Dich da am freitag auf den
       holzweg gefuehrt habe - ich war wohl nicht mehr ganz frisch.
       jetzt, wo ich Dein bsp. sehe, faellt es mir wie schuppen von
       den augen - so kann das auch nicht funktionieren, weil:

    a) die prototypische vererbung, wie sie auch fuer Deine
          beispielhaft vorgegebenen methoden in frage kaeme, nur
          ueber den prototypen des jeweiligen objekt-konstruktors
          erfolgen kann - der konstruktor ist in Deinem fall immer
       b) [[Object]], denn objektliterale sind nun mal [Object]-
          objekte. und hier liegt der hase auch im pfeffer:
       c) [Object.prototype] laesst sich nicht ueberschreiben und
          ist und bleibt damit immer die atomare struktur {} - also
          selbst ein leeres [Object]-objekt.

    hiermit revidiere ich meine am freitag gemachten aussagen.

    vererbung, so wie Du sie moechtest, ist fuer objektliterale
       unerreichbar.

    das fuers erste ... ich meld' mich gleich nochmal zurueck

    bis dann - peterS. - pseliger@gmx.net

    --
    »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
    Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
    ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
    1. gruss Christian,

      ah ja, sehr schoen ... ich sehe molily war schon vor mir am ball.
         deshalb praezisiere ich nochmals:

      c) [Object.prototype] laesst sich nicht ueberschreiben -

      im sinne von: Object.prototype = new Irgendwas(); -

      sondern nur erweitern, mit allen effekten, wie sie Dir molily
         schon beschrieb.

      wenn Du diese nicht in kauf nehemn moechtest, kaeme fuer Dich
         nur noch schnittstellenvererbung in frage, welche in JavaScript
         ueber delegation an die jedem [Function]-object zueigenen methoden
         [apply] bzw. [call] abgebildet wird.

      Du koenntest also einem wie auch immer gearteten basis-objekt
         die von Dir gewuenschten methoden mitgeben. Deine durch objekt-
         literale erzeugten anderen objekte rufen dann diese basis-objekt-
         methoden in ihrem jeweils eigenen kontext auf - bsp.:

      ~~~javascript var holder = {

      foo: "foo",
           bar: "bar",
           showFoo: function () {
             alert(this.foo);
           },
           showBar: function () {
             alert(this.bar);
           }
         };

      var myFoo = {
           foo: "myFoo"
         };
         var myBar = {
           bar: "myBar"
         };

      alert(holder.foo); // "foo";
         holder.showFoo(); // "foo";

      alert(holder.bar); // "bar";
         holder.showBar(); // "bar";

      alert(myFoo.foo); // "myFoo";
         holder.showFoo.call(myFoo); // "myFoo"; // ergebnis der methode [holder.showFoo] im kontext von [myFoo];

      alert(myBar.bar); // "myBar";
         holder.showBar.call(myBar); // "myBar"; // ergebnis der methode [holder.showBar] im kontext von [myBar];

        
        
        
         by(t)e by(t)e - peterS. - pseliger@gmx.net  
        
        
      
      -- 
      »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.  
      Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - [Douglas Crockford](http://javascript.crockford.com/)  
        
      ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
      
      1. Hi,

        danke für die gute Erklärung!!

        alert(myBar.bar); // "myBar";
           holder.showBar.call(myBar); // "myBar"; // ergebnis der methode [holder.showBar] im kontext von [myBar];[/code]

        ich will aber schon gerne die Basismethoden so nutzen:

        myBar.showBar();

        statt

        holder.showBar.call(myBar);

        Ich werd es wohl doch über Prototypen machen müssen, und dann doch einen Konstruktor für jedes objekt.

        Gruß
        Christian

        1. hallo again Christian,

          danke für die gute Erklärung!!

          naja, dass war ich Dir und mir nach der freitaeglichen *fast pleite*
             einfach schuldig ;-)

          ich will aber schon gerne die Basismethoden so nutzen:

          myBar.showBar(); ...  statt ... holder.showBar.call(myBar);

          Ich werd es wohl doch über Prototypen machen müssen, und dann
          doch einen Konstruktor für jedes objekt.

          um gottes willen - nein. nimm Doch lieber die werkzeuge zur
             hand, die das sprachkonzept schon passend fuer solche faelle
             zur verfuegung stellt - gleichnisversuch:

          Du fummelst doch hoffentlich nicht erst mit dem dietrich in
             einem schloss rum, dessen schluessel Du ebenfalls in der
             hand haelst.

          zeig mal etwas mehr code ... so in die richtung *ausgangsbasis
             versus gewuenschtes verhalten* - vielleicht gibt es noch ganz
             andere loesungsansaetze.

          so long - peterS. - pseliger@gmx.net

          --
          »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
          Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
          ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
          1. Hi,

            zeig mal etwas mehr code ... so in die richtung *ausgangsbasis
               versus gewuenschtes verhalten* - vielleicht gibt es noch ganz
               andere loesungsansaetze.

            in ASP.NET gibt es ja Servercontrols, also halt zB eine Textbox. Und UserControls, die aus mehreren Controls bestehen und woanders eingebunden werden (auch öfters) und zusammen eine logische Einheit bilden. Bestimmte Controls (solche, die in formularen verwendet werden, <input>, <select>, ...) möchte ich clientseitig einfach zugreifbar machen.
            ASP.NET erzeugt ja immer eine ClientID, die uU ziemlich lang sein kann.
            wenn ich also an die Textbox XY rankommen will müsste ich schreiben:

            var textbox = document.getElementById('<%= txtBla.ClientID %>');

            bei verschachtelten UserControls dann mit <%= UserControl1.FindControl("Textbox1").ClientID %>.

            Weiterhin suche ich nach einer Möglichkeit zB alle Formularelemente eines Usercontrols zu resetten oder zu disablen.

            Möchte ich alle Elemente eines UserControls resetten hab ich bisher geschrieben:

            var textbox1 = document.getElementById('<%= txtBla.ClientID %>');
            var textbox2 = document.getElementById('<%= txtBla.ClientID %>');
            var textbox3 = document.getElementById('<%= txtBla.ClientID %>');
            var textbox4 = document.getElementById('<%= txtBla.ClientID %>');

            textbox1.value = "";
            usw....

            beim disablen analog.

            Das ist ziemlich nervig...

            Idee: Ich gehe serverseitig alle Controls der Seite rekursiv durch und baue mir ein JavaScript Objekt zusammen, welches ich an die Seite mit rausrendere. Die Struktur ist dabei die selbe wie serverseitig.

            statt

            var textbox = document.getElementById('<%= txtBla.ClientID %>');
            textbox.disabled = true;

            habe ich direkt die Textbox mit ihrer (serverseitigen) ID als globale Variable und könnte so drauf zugreifen:

            txtBla.disabled = true;

            UserControls sollen als Unterobjekte dargestellt werden:

            UserControl1.txtMyTextbox.disabled = true;

            (die ClientID setzt sich ähnlich zusammen: Usercontrol1_txtMyTextbox)
            (Man könnte ja die selbe server ID für verschiedene Element in verschiedenen Usercontrols verwenden).

            Serverseitig geh ich also alles rekusriv durch und gebe aus:

            var txtBla = document.getElementById(...);

            Bei den UserControls brauch ich dann eben Objekte.

            var UserControl1 =
            {
               txtBla: document.getElementById(...),
               txt1: ...,
               InnerUserControl: {...}
            };

            Jedes Usercontrol soll also ein paar Methoden von einer Basisklasse erben. Zum disablen geh ich also alle properties (for(var control in this)) durch und setze sie auf disabled (wenn das member ein object ist).

            Damit hab ich obiges Problem sehr vereinfacht.

            Natürlich könnte ich auch serverseitig einen Konstruktor für jedes UserControl generieren lassen und dann halt eine (die einzige) Instanz davon erzeugen, aber das find ich halt nicht so schön, da man ja eigentlich keinen Konstruktor braucht, da eh nur eine Instanz existiert.

            Gruß
            Christian

            1. gruss Christian,

              ...
              [sehr viele informationen]
              ...

              es wird wahrscheinlich so sein, dass ich Dein problem nicht ganz
                 verstanden habe, trotzdem aeussere ich mal ein paar gedanken dazu.

              idealerweise bildet doch schon die html-dokumenten-strukur (der
                 DOM-baum) die beziehungen der controls zu- und untereinander ab.
                 ausserdem sollten sich schon z.b. anhand des element-typs oder
                 der css-klassen-namen von formular-elementen alle merkmale zur
                 identifizierung eines bestimmten control-typs treffen lassen.

              sind diese voraussetzungen gegeben, wuerde ich tatsaechlich einen
                 voellig anderen ansatz waehlen. zuerst liesse ich einen *build*-
                 prozess auf das DOM los, um control-sup- und sub-strukturen anhand
                 der gerade erwaehnten merkmale >>struktur<< und >>eigenschaften<<
                 zu identifizieren. jedes dieser elemente wuerde ich dann an genau
                 den JavaScript-konstruktor weiterreichen, der in seiner abstraktion
                 dem jeweiligen ASP-pendant entspraeche und mit seiner internen
                 logik exakt auf die von Dir erwaehnten client-/ und oder server-
                 seitigen beduerfnisse zugeschnitten waere.

              das ist bei weiten nicht so theoretisch wie es sich anhoert. auch
                 die clientseitige umsetzung ist nicht so komplex wie es auf den
                 ersten blick erscheinen mag.

              die vorteile fuer mich liegen im zwang zur sauberen implementierung
                 des html-codes, denn dessen struktur muss schon die zu bearbeitende
                 objektstruktur der serverseite widerspiegeln. die fuer den bearbei-
                 tungsprozess relevante ASP-objekt/-klassenstruktur der controls
                 kommt auf der clientseite erneut zum einsatz.

              Weiterhin suche ich nach einer Möglichkeit zB alle Formularelemente
              eines Usercontrols zu resetten oder zu disablen.

              auf dieser grundlage liesse sich doch oben geausserter wunsch relativ
                 einfach im client formulieren.

              so long - peterS. - pseliger@gmx.net

              --
              »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
              Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
              ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]
              1. Hi,

                es wird wahrscheinlich so sein, dass ich Dein problem nicht ganz
                   verstanden habe, trotzdem aeussere ich mal ein paar gedanken dazu.

                vermutlich.

                idealerweise bildet doch schon die html-dokumenten-strukur (der
                   DOM-baum) die beziehungen der controls zu- und untereinander ab.
                   ausserdem sollten sich schon z.b. anhand des element-typs oder
                   der css-klassen-namen von formular-elementen alle merkmale zur
                   identifizierung eines bestimmten control-typs treffen lassen.

                idealerweise... Wenn man in einem größeren Team arbeitet, weiß ich nicht, wie jeder einzelne seine Oberflächen strukturiert... Ich will ja nicht auch nicht alle Elemente eines Typs disablen sondern die, die logisch zu einer Gruppe gehören.

                Habe noch rumprobiert, mit den Literalen und habe folgendes festgestellt:

                  
                  function MyBase()  
                  {  
                   this.Reset = function()  
                   {  
                    alert(this);  
                   };  
                  }  
                  
                  var Controls =  
                  {  
                   constructor: MyBase,  
                   a:1,  
                   UC1:  
                   {  
                    constructor: MyBase,  
                    b: 1,  
                    UC2:  
                    {  
                     constructor: MyBase,  
                     c:1  
                    }  
                   }  
                  };  
                  
                  Controls.constructor();  
                  Controls.UC1.constructor();  
                  Controls.UC1.UC2.constructor();  
                  
                  Controls.UC1.UC2.Reset();  
                  
                
                

                Das geht :-) !

                Gruß
                Christian

                1. hallo Christian,

                  es wird wahrscheinlich so sein, dass ich Dein problem nicht ganz
                     verstanden habe ...

                  vermutlich.

                  idealerweise bildet doch schon die html-dokumenten-strukur (der
                     DOM-baum) die beziehungen der controls zu- und untereinander ab.
                     ...

                  ...
                  idealerweise... Wenn man in einem größeren Team arbeitet, weiß ich nicht,
                  wie jeder einzelne seine Oberflächen strukturiert...

                  dann sollte dieser zustand verbesserung erfahren.

                  ... Ich will ja nicht auch nicht alle Elemente eines Typs disablen sondern
                  die, die logisch zu einer Gruppe gehören.

                  Habe noch rumprobiert, mit den Literalen und habe folgendes festgestellt:

                  function MyBase()

                  {
                     this.Reset = function()
                     {
                      alert(this);
                     };
                    }

                  var Controls =
                    {
                     constructor: MyBase,
                     a:1,
                     UC1:
                     {
                      constructor: MyBase,
                      b: 1,
                      UC2:
                      {
                       constructor: MyBase,
                       c:1
                      }
                     }
                    };

                  Controls.constructor();
                    Controls.UC1.constructor();
                    Controls.UC1.UC2.constructor();

                  Controls.UC1.UC2.Reset();

                  
                  >   
                  > Das geht :-) !  
                    
                     schon, aber Du musst fuer dieses ergebnis nicht unbedingt den [constructor]  
                     zu einer art expliziet aufzurufender \*super\* methode umbiegen, nur um den  
                     [this]-kontext fuer jedes objektliteral herzustellen - das gleiche resultat  
                     laesst sich einfacher auch ohne [constructor]-eigenschaft erzielen:  
                    
                    
                     ~~~javascript
                  var provideResetContext = function () {  
                    
                       return (function () {  
                         alert(this + "\n" + ((this.toSource) ? (this.toSource()) : (""))); // [Object.toSource] : geckos only;  
                       });  
                     };  
                     var Controls = {  
                    
                       reset: provideResetContext(),  
                       a: 1,  
                       UC1: {  
                         reset: provideResetContext(),  
                         b: 1,  
                         UC2: {  
                           reset: provideResetContext(),  
                           c:1  
                         }  
                       }  
                     };  
                     Controls.reset();  
                     Controls.UC1.reset();  
                     Controls.UC1.UC2.reset();
                  

                  lass die folgende zeile mal auf die JavaScript-konsole eines mozillas los:

                  var provideResetContext = function () {return (function () {alert(this + "\n" + ((this.toSource) ? (this.toSource()) : ("")));});};var Controls = {reset: provideResetContext(),a: 1,UC1: {reset: provideResetContext(),b: 1,UC2: {reset: provideResetContext(),c:1}}};Controls.reset();Controls.UC1.reset();Controls.UC1.UC2.reset();

                  so long - peterS. - pseliger@gmx.net

                  --
                  »Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
                  Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
                  ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]