peterS.: Quadratur des Kreises lösen? DOM- und Sprachkern-Api versöhnen?

gruss in die Runde,

welches *wording* beschreibt das vorgehen im folgenden einfach
gehaltenen beispiel am besten: Functor? || MixIn? || Interface?

code z.b. durch *copy and paste* der jconsole zur verfuegung
stellen - [http:jconsole.com]:

// unterstuetzender code:  
document.getElmPosAbsolute = (function (elm) {  
  
 var x = 0, y = 0;  
 if (elm && elm.offsetParent) {  
  
  x = elm.offsetLeft;  
  y = elm.offsetTop;  
  
  elm = elm.offsetParent;  
  while (elm) {  
  
   x = x + elm.offsetLeft;  
   y = y + elm.offsetTop;  
  
   elm = elm.offsetParent;  
  }  
 }  
 return { "left":x, "top":y };  
});  
  
// *fragestellungsspezifischer* code:  
var NodeFunctor = (function () { // Functor||MixIn||Interface?  
  
 this.getPosAbsolute = (function () {  
  
  return document.getElmPosAbsolute(this);  
 });  
});  
  
  
var elm = document.getElementsByTagName("textarea")[0];  
  
  
// welchen namen gibt man diesem spezifischen anwendungsfall?  
NodeFunctor.call(elm); // Functor? || MixIn? || Interface?  
  
  
var posDocMethod = document.getElmPosAbsolute(elm);  
var posElmMethod = elm.getPosAbsolute();  
  
print("posDocMethod.left : " + posDocMethod.left);  
print("posElmMethod.left : " + posElmMethod.left);  
print("posDocMethod.top : " + posDocMethod.top);  
print("posElmMethod.top : " + posElmMethod.top);  
  
print("elm : " + elm);  
props(elm);  
  
print("elm.constructor : " + elm.constructor);  
print("elm.prototype : " + elm.prototype);

und gleich die naechste frage - warum benutzt keines der grossen
frameworks wie z.b. die YUI-lib bzw. keine der kleinen populaeren
bibliotheken wie jQuery dieses auf spaeter bindung beruhende
delegationskonzept, um die zwei in der syntax so unterschiedlichen
schreibkonvention - an namensraeume gebundene statische/generische
methoden versus *chainable* methoden irgendwelcher objekt-wrapper -
miteiander zu versöhnen?

gerade das permanennte neueintueten bzw. das erzeugen irgendwelcher
instanzen im hintergrund geht doch auf kosten der leistungsfaehigkeit
z.b von jQuery und frisst in der anwendung den anfaeglichen vorteil
ausdrucksstarken kurzen codes gleich wieder auf.
da nimmt man doch lieber die gefuehlten nachteile einer *old school*-
schreibweise wie z.b. in der anwendung der YUI-lib in kauf, wissend,
dass dort bei DOM-manipulationen nicht permanent teuer im hintergrund
gearbeitet wird - oder etwa nicht?

warum *wrappt* jQuery ueberhaupt, wo es doch zmindest fuer mich den
anschein hat, dass sich *chainability* einfacher und eben auch
billiger mit Funkturen?/Interfaces? erreichen liesse? warum nutzt die
YUI-lib nicht diesen ansatz, um auf einfache weisse schon vorhandene
statisch/generisch implementierte funktionalitaet zusaetzlich ueber
diesen ansatz *chainable* zur verfuegung zu stellen?

hab' ich was verpasst? etwas nicht richtig verstanden? blamier ich
mich mit dieser fragerei gerade bis auf die knochen?

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,

    hab' ich was verpasst? etwas nicht richtig verstanden? blamier ich
    mich mit dieser fragerei gerade bis auf die knochen?

    Hmm, so spontan: Nein.

    Ich werde mir dein Beispiel nochmal durch den Kopf, bzw. die Praxis gehen lassen. Vielleicht ändert sich meine Meinung dann ja noch (theoretisch wahrscheinlich nicht, höchstens aus praktischen Erwägungen heraus).

    Aber mir fällt dazu eine Aussage von Richard Cornford über Prototype ein:
    "Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript."

    Und daß sich z.B. jQuery auf Browserweichen stützt, die zudem auch noch im höchsten Maße unzuverlässig sind, hatten wir ja hier schon mal thematisiert. Also: nicht wundern ...

    Gruß, Cybaer

    --
    Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
    (Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
    1. [latex]Mae  govannen![/latex]

      Aber mir fällt dazu eine Aussage von Richard Cornford über Prototype ein:
      "Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript."

      Und daß sich z.B. jQuery auf Browserweichen stützt, die zudem auch noch im höchsten Maße unzuverlässig sind, hatten wir ja hier schon mal thematisiert. Also: nicht wundern ...

      Ach ja *seufz*
      Die Qualität von prototype und jquery ..
      Ein immerwährendes Thema in comp.lang.javascript ;)

      Cü,

      Kai

      --
      Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
      Sacrifice - the future has it's price
      And today is only yesterday's tomorrow
      selfcode sh:( fo:| ch:? rl:( br:< n4:# ie:{ mo:| va:) js:) de:> zu:) fl:( ss:| ls:?
    2. gruss Cybaer,

      Ich werde mir dein Beispiel nochmal durch den Kopf, bzw. die Praxis gehen lassen.

      *praxis* hab' ich schon - natuerlich genauso spartanisch, wie Du es schon kennst -
      einfach mal durch den code wuehlen, die kommentare lesen und das bsp. ausprobieren.

      die besser lesbare implemantation der Funktoren [[NodeFunctor]] bzw. [[NodeListFunctor]]
      gibt es hier: http://www.pseliger.de/jsExtendedApi/jsApi.bundles.DOM.getters.dev.js

      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:]
  2. Hi,

    // welchen namen gibt man diesem spezifischen anwendungsfall?
    NodeFunctor.call(elm); // Functor? || MixIn? || Interface?

    So, nach einer Nacht drüber schlafen, meine Vorschläge:

    • NodePrototyper (OK, sachlich falsch, ggf. irreführend, aber davonabgesehen, kann man IMHO den Sinn/die Anwendung sofort verstehen)
    • NodeEnhancer
    • NodeBinding / NodeBinder
    • FunctionBinder

    Gruß, Cybaer

    --
    Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
    (Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
    1. hallo again Cybaer,

      // welchen namen gibt man diesem spezifischen anwendungsfall?
      NodeFunctor.call(elm); // Functor? || MixIn? || Interface?

      So, nach einer Nacht drüber schlafen, meine Vorschläge:

      • NodePrototyper (OK, sachlich falsch, ggf. irreführend, aber davonabgesehen, »»   kann man IMHO den Sinn/die Anwendung sofort verstehen)
      • NodeEnhancer
      • NodeBinding / NodeBinder
      • FunctionBinder

      vielen dank.

      [Enhancer] bzw. [Binder] sind ja schon mal zwei - warum kommt fuer dich
      das [Interface] nicht in frage? - fuer das bsp. dann [[NodeListInterface]]
      bzw. [[NodeInterface]].

      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,

        warum kommt fuer dich
        das [Interface] nicht in frage? - fuer das bsp. dann [[NodeListInterface]]
        bzw. [[NodeInterface]].

        Rein gefühlsmäßig. Ein "Interface" ist mir zu unbestimmt. Unter einem Enhancer bzw. Binder kann ich mir *sofort konkret* was vorstellen. Nämlich, daß ein Node erweitert wird (aha, vermutlich um eine Methode), bzw. daß an den Node etwas gebunden wird (dito). Interface kann IMHO dagegen auch was ganz anderes sein ...

        Gruß, Cybaer

        --
        Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
        (Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
        1. gruss Cybaer,

          Rein gefühlsmäßig. Ein "Interface" ist mir zu unbestimmt. ...
          ...
          ...Interface kann IMHO dagegen auch was ganz anderes sein ...

          stellt [[EventDispatcher]] in folgendem verkuerztem bsp. jedem
          angemeldeten objekt ein [EventTarget]-interface zur verfuegung,
          oder ordnest Du das auch unter "enhancing" / "binding" ein?

          /*  
           wie inzwischen ueblich, folgenden code mal in  
           die [[link:http://jconsole.com/]] reinschmeissen:  
          */  
          this.EventDispatcher = (function () { // [[EventDispatcher]]-Singleton  
            
           /*  
            viel platz fuer *private protected* helferfunktionalitaet  
           */  
           var Event = (function (target, type) {/*  
            
            ... nicht ganz so viel code ... */  
           });  
           var EventListener = (function (thisTarget, type, handler) {/*  
            
            ... etwas mehr code ... */  
           });  
           var EventTarget = (function () {  
            
            var events = {};  
            
            this.addEventListener = (function (type, handler) {/* ... viel code ... */});  
            this.removeEventListener = (function (type, handler) {/* ... viel code ... */});  
            this.dispatchEvent = (function (evt) {/* ... viel code ... */});  
           });  
            
           return {  
            
            register: (function (obj) {EventTarget.call(obj);}), // [*1]  
            unsubscribe: (function (obj) {/* ... nicht ganz so viel code ... */})  
           };  
            
          })();  
            
            
          this.Queue = (function () { // [[Queue]]-Konstruktor.  
            
           /*  
            jedes [Queue] objekt bekommt jetzt auch [EventTarget]-  
            funktionalitaet zugewiesen.  
            
            das objekt wird an dieser stelle *einfach nur signiert*?  
            bitte korrigiert mich.  
            
            spaeter greift dann die bindung an das konstrukt wofuer  
            ich einen passenden begriff, auch gerne in analogie zu  
            anderen programmiersprachen, suche.  
            
            was passiert hier also von der begrifflichkeit her:  
            
            - das objekt implementiert ein Interface?  
            - das objekt meldet sich am Funktor an?  
            - das objekt wird an den Funktor gebunden?  
            - ... ?  
           */  
          //var timer = new Date();  
            
           EventDispatcher.register(this); // siehe [*1] : [register]  
            
          //print((new Date() - timer) + " msec");  
            
           var self = this, list = [];  
            
           var onEnqueue = (function (obj) {  
            
            self.dispatchEvent({target: self, type: "onEnqueue", elm: obj/*, even more key:value pairs */});  
           });  
           var onDequeue = (function (obj) {  
            
            self.dispatchEvent({target: self, type: "onDequeue", elm: obj/*, even more key:value pairs */});  
           });  
           var onEmpty = (function () {  
            
            self.dispatchEvent({target: self, type: "onEmpty"/*, even more key:value pairs */});  
           });  
            
           this.enqueue = (function (obj) {  
            
            list.push(obj);  
            this.length = list.length;  
            
            onEnqueue(obj);  
           });  
           this.dequeue = (function () {  
            
            var obj = list.shift();  
           //onDequeue(obj);  
            if (list.length === 0) {  
            
             onEmpty();  
            }  
            onDequeue(obj);  
            
            return obj;  
           });  
            
           this.length = 0;  
          });  
            
            
          var myQueue = new Queue();  
            
          print(myQueue);  
          props(myQueue);
          

          vielen dank fuer Deine geduld - 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. stellt [[EventDispatcher]] in folgendem verkuerztem bsp. jedem
            angemeldeten objekt ein [EventTarget]-interface zur verfuegung,
            oder ordnest Du das auch unter "enhancing" / "binding" ein?

            Ich hab übrigens deine Idee hier mal praktisch angewandt.

            Was die Diskussion angeht, kann ich da wenig zu sagen und mir sind die theoretischen Debatten auch zu abgehoben, mir fehlen auch die Fachbegriffe. Aber prinzipiell halte ich den Ansatz für sehr gut (fast schon genial). Ich muss zugegeben, dass mir einerseits die Abstraktion Schwierigkeiten gemacht hat und anderseits immer das Gefühl hatte, das ist zu einfach.

            vielen dank fuer Deine geduld - so long - peterS. - pseliger@gmx.net

            Das muss man wirklich mal sagen, wenn man die Reaktionen in de.comp.lang.javascript anschaut. Die spinnen (wobei das bei Herrn Lahn nichts neues ist).

            Struppi.

            1. gruss Struppi,

              Ich hab übrigens deine Idee hier mal praktisch angewandt.

              hab' ich schon registriert, danke fuer die ehre, praktische anwendung
              zu finden ;-)

              Was die Diskussion angeht, kann ich da wenig zu sagen und mir sind
              die theoretischen Debatten auch zu abgehoben, ...

              ich bin auch kein theoretiker, und so abgehoben ist das nicht. gerade
              in diesem fall brauche ich auch absolute sicherheit in der beschreibung
              dieses konzepts, denn im falle eines [[Funktors]] liesse sich ebenjener
              sogar als eigene abstraktion im scripting host umsetzen.

              ... mir fehlen auch die Fachbegriffe.

              das geht mir genauso - ich bin »interessierter laie« (TM by molily) und
              (langsamer) aber stetiger selbsterarbeiter, so wie Du auch - deswegen
              reite ich ja auch so penetrant auf diesem thema herum.

              Aber prinzipiell halte ich den Ansatz für sehr gut (fast schon genial).
              Ich muss zugegeben, dass mir einerseits die Abstraktion Schwierigkeiten
              gemacht hat und anderseits immer das Gefühl hatte, das ist zu einfach.

              exakt. dasselbe bei mir ... ich suche pausenlos nach einem fehler und warte
              darauf, dass mir code um die ohren fliegt, aber *es tut, ...immer, ...alles*
              in den mir zur verfuegung stehenden "vier grossen". deswegen ja auch mein
              ratlos bis verzweifelt klingendes eroeffnungsposting.

              vielen dank fuer Deine geduld - so long - peterS. - pseliger@gmx.net

              Das muss man wirklich mal sagen, wenn man die Reaktionen in
              de.comp.lang.javascript anschaut. Die spinnen (wobei das bei
              Herrn Lahn nichts neues ist).

              ... newsgroup halt. ich wusste, was mich erwartet. solange 5% bis 10%
              fachlich verwertbares 'bei rum kommt, ist es ok ... 100-prozentige
              anmache bei 0% fachlichem beitrag disqualifizieren sich ja dann auch
              in aller oeffentlichkeit ganz von allein.

              das momentane aergernis besteht darin, dass sich dort entweder die jungs
              bisher nicht die muehe gemacht zu haben scheinen, ueberhaupt verstehen zu
              wollen, was der eigentliche antrieb hinter diesem loesungsansatz ist, oder
              ich echt nicht in der lage war, ganau das einigermassen verstaendlich
              darzulegen.

              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:]