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

[peterS.]

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. - [e-mail]

[Cybaer]

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

[Kai345]

[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

[peterS.]

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. - [e-mail]

[Cybaer]

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

[peterS.]

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. - [e-mail]

[Cybaer]

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

[peterS.]

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. - [e-mail]

[Struppi]

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. - [e-mail]

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.

[peterS.]

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. - [e-mail]

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. - [e-mail]