method modifiers in addition to "bind"

# Peter Seliger (14 years ago)

Since »Function.prototype.bind« did make it into ECMAScript's 5th Edition, how about having implemented prototypal method modifiers »before«, »after« and »around« into next Versions of JavaScript?

And in particular for »around«, what should the arguments precedence of the around wrapping function look like?

Peter

# Andrea Giammarchi (14 years ago)

that looks like a wrap to me ... what's the connection with bind() exactly?

Also not sure you are talking about dispatched Events ("before", "around", "after") or some other topic

br

# Peter Seliger (14 years ago)

that looks like a wrap to me ... what's the connection with bind() exactly?

Also not sure you are talking about dispatched Events ("before", "around", "after") or some other topic

Sorry for not having pointed it out clearly enough. I'm talking about before/after/around as they are known from Aspect Oriented Programming.

The connection to bind, I thought, was that all of them do modify other methods. Therefore I did choose the above subject instead of mentioning AOP in the first place.

Peter

# David Bruant (14 years ago)

Le 16/02/2012 03:32, Peter Seliger a écrit :

that looks like a wrap to me ... what's the connection with bind()
exactly?

Also not sure you are talking about dispatched Events ("before",
"around", "after") or some other topic

Sorry for not having pointed it out clearly enough. I'm talking about before/after/around as they are known from Aspect Oriented Programming.

The connection to bind, I thought, was that all of them do modify other methods. Therefore I did choose the above subject instead of mentioning AOP in the first place.

Can you show some examples of what it would look like? Is there a widespread use of such constructs in JavaScript? I can't recall having seen such things.

A while ago, I did start a library using "before", for a sort of runtime type checking (replacing a function with another function that does the same thing, but with type checking for both input and output). Having started such a thing, I soon realized it was hard to use my library in a non-intrusive way (probably a good use case for macros).

I'm not sure to what extent my experience reflects how the general use case for methods modifiers in JS would be, though.

# Peter Seliger (14 years ago)

On Thu, Feb 16, 2012 at 9:38 AM, David Bruant <bruant.d at gmail.com> wrote:

Is there a widespread use of such constructs in JavaScript? I can't recall having seen such things.

It comes closest to Malte Ubl's JavaScript Meta Object System "JOOSE". "before", "after" and "around" are optional keywords of a configuration object that describes e.g. "Joose" classes or "Joose" roles. Resolving conflicts of equally named (homonymic?) methods at construction time is theirs main purpose.

Can you show some examples of what it would look like?

Joose examples can be found at joose.github.com/Joose/doc/html/Joose/Manual/MethodModifiers.html

A prototypal implementation of that trio might look like this attempt of mine petsel/javascript-api-extensions/blob/master/core/Function/Function.modifiers.aop.base.js

I recently did make use of "around" a lot in order to specialize a generic view component depending on its DOM environment and the device that runs it.

This view component is a singleton module that transforms DOM structures. But it does not transform plainly. A properly rendered view relies on DOM measurements and the transformation itself shall only take place within specific environments.

"transformDOMStructure" was this modules sole public method.

But in order to keep this components source code unchanged and also ensuring the above mentioned flexibility I could shape out what AOP seems to call "Cross Cutting Point"s (CCP).

"isTransformDOMStructure" and "getDOMMeasurementsOfCurrentView" now are two additional public methods that get used by "transformDOMStructure".

Definitions of whether a certain transformation should take place or not as well as descriptions of how to measure a certain DOM-Fragment now can be written into contollers/presenters that, in my understanding of AOP, also could be called aspects (of this generic util). Such a controller has to provide code that wraps additional functionality around both methods that got identified as CCPs.

myUtil.isTransformDOMStructure = myUtil.isTransformDOMStructure.around(function (

isTransformDOMStructureEnclosed,   isTransformDOMStructureAround,   initialArguments/,   target/

) {

// ... specification.

}/, target/);

"around" creates a wrapper that has access to the former method ("...Enclosed"), to itself ("...Around" - in case there is need of it), to the "arguments" object of the initial function call and to "target" that, optionally can be provided as second parameter to "around".

A second use case was this often mentioned "logging". By walking a globally namespaced 3rd party library recursively whilst wrapping every function object it was easy to log a methods name, its object path and all of its arguments.

Peter