Ich bin gerade auf zwei interessante Artikel gestossen. Vielleicht ist das auch für euch interessant.
Intercepting JavaScript Methods
Ruby style metaprogramming in javascript
Wäre auch schön zu hören, was Ihr davon haltet. Ich persönlich arbeite sehr viel mit Interceptions. Jetzt nicht in JavaScript, da war es mir neu, sondern allgemein.
JavaScript Interceptions und Metaprogramming
gepostet vor 17 Jahre, 4 Monate von Agmemon
gepostet vor 17 Jahre, 4 Monate von COrthbandt
Da hier niemand antwortet werde ich das mal tun, denn die beiden Beiträge sind durchaus lesenswert.
Das meta programming ist interessant, sieht für mich aber eher nach einer "weil's geht"-Spielerei aus. Gegen "weil's geht"-Spielereien ist absolut nichts einzuwenden, allerdings muss man sich beim Produktiveinsatz immer überlegen ob es netto etwas bringt.
Javascript hat konzeptbedingt massive Performanceprobleme (ständige Hash-Lookups, keine statischen Typen), da muss man mächtig aufpassen dass man sich kein dickes fettes Loch buddelt. Zusätzliche Indirektion ist da eine IMHO gefährliche Sache. Insbesondere wenn sie als Basistechnik eingesetzt wird und somit in einem realen Projekt nur schwer wieder loszuwerden ist.
Die Interceptions sind da schon sinnvoller. Allerdings sehe ich nicht so richtig, was daran in Javascript so revolutionär sein soll.
Mal ein Beispiel: Wir kapseln unsere XmlHTTPRequests in einer Klasse, das sieht dann so aus:
var xRPC=new PitRPC("parsec.xrq","padd");
xRPC.SetParam("f",iFc);
xRPC.OnSucceed=function(){ ... };
xRPC.OnFail=function(){ ... };
xRPC.Send();
OnSucceed und OnFail als Callback/Event/Interception Handler (ist irgendwie alles das gleiche) sind hier der zentrale Wirkmechanismus.
Javascript bietet sich besonders für solche Konstrukte an, da sie durch fehlenden Zugriffsschutz und das generische Objektkonzept trival (naja meistens) zu implementieren sind.
Die erweiterte Idee der Interceptions (ich setze einen Callback auf eine Funktion die gar nicht dafür gedacht ist) ist ja ganz nett, fällt aber unter Umständen auch schnell zusammen, weil
Also zusammengefasst: Wenn eine Library dafür designed und vorbereitet ist kann man damit viel machen und es ist in Javascript auch sehr effizient. Wenn man mit diesen Interceptions Amok läuft und kreuz und quer Funktionen erweitert/modifziert kann man sich auch sehr sehr schön in den Fuss schiessen.
my 0.02€
Das meta programming ist interessant, sieht für mich aber eher nach einer "weil's geht"-Spielerei aus. Gegen "weil's geht"-Spielereien ist absolut nichts einzuwenden, allerdings muss man sich beim Produktiveinsatz immer überlegen ob es netto etwas bringt.
Javascript hat konzeptbedingt massive Performanceprobleme (ständige Hash-Lookups, keine statischen Typen), da muss man mächtig aufpassen dass man sich kein dickes fettes Loch buddelt. Zusätzliche Indirektion ist da eine IMHO gefährliche Sache. Insbesondere wenn sie als Basistechnik eingesetzt wird und somit in einem realen Projekt nur schwer wieder loszuwerden ist.
Die Interceptions sind da schon sinnvoller. Allerdings sehe ich nicht so richtig, was daran in Javascript so revolutionär sein soll.
Mal ein Beispiel: Wir kapseln unsere XmlHTTPRequests in einer Klasse, das sieht dann so aus:
var xRPC=new PitRPC("parsec.xrq","padd");
xRPC.SetParam("f",iFc);
xRPC.OnSucceed=function(){ ... };
xRPC.OnFail=function(){ ... };
xRPC.Send();
OnSucceed und OnFail als Callback/Event/Interception Handler (ist irgendwie alles das gleiche) sind hier der zentrale Wirkmechanismus.
Javascript bietet sich besonders für solche Konstrukte an, da sie durch fehlenden Zugriffsschutz und das generische Objektkonzept trival (naja meistens) zu implementieren sind.
Die erweiterte Idee der Interceptions (ich setze einen Callback auf eine Funktion die gar nicht dafür gedacht ist) ist ja ganz nett, fällt aber unter Umständen auch schnell zusammen, weil
- die Funktionen vom Design her dafür ausgelegt sein müssen
- einem bei Änderungen an privaten Interfaces alles um die Ohren fliegt
- dadurch die Implementation plötzlich zum öffentlichen Interface wird
- andere Clients des Interface durch die veränderte Implementation gestört werden können
Also zusammengefasst: Wenn eine Library dafür designed und vorbereitet ist kann man damit viel machen und es ist in Javascript auch sehr effizient. Wenn man mit diesen Interceptions Amok läuft und kreuz und quer Funktionen erweitert/modifziert kann man sich auch sehr sehr schön in den Fuss schiessen.
my 0.02€
gepostet vor 17 Jahre, 4 Monate von Agmemon
Du hast sicherlich recht, dass man bei der Verwendung stark aufpassen muss, gerade, da Interceptions nicht umbedingt zum definiertem Sprachumfang gehören. Es kann aber sehr sinnvoll sein, um so in Abläufe eingreifen zu können, auf die man normalerweise keinen Zugriff hat. Ich arbeite gerade im Studium an einer JEE5 Anwendung, wo Callbacks und Interceptions zum definiertem Umfang gehören und lebensnotwendig sind. Callbacks werden verwendet, um auf den Lebenszyklus von Entitäten zu reagieren, da diese die Persistenz nicht selbst implementieren. Da wird es von einem PersistenzManager gehandhabt, auf den man keinen direkten Einfluss nehmen kann. Interceptions verwende ich in der Anwendung zum Profiling. Das wäre auch so das Einsatzgebiet, dass ich für Interceptions in JavaScript interessant fände.