Methods: automatic binding on read?
You mean "automatic binding with memoization on read", I hope.
Otherwise you break o.m === o.m.
This can be implemented with accessors and weakmaps, of course. That says two things to me:
-
It ain't cheap so should not be default, esp. not for method definition shorthand.
-
We should let the cows make a pavement-worthy path.
On Apr 13, 2012, at 23:40 , Brendan Eich wrote:
You mean "automatic binding with memoization on read", I hope.
Otherwise you break o.m === o.m.
That makes sense, yes.
This can be implemented with accessors and weakmaps, of course. That says two things to me:
It ain't cheap so should not be default, esp. not for method definition shorthand.
We should let the cows make a pavement-worthy path.
What would be nice to have would be the following (with prettier wrapping):
function myDefineMethod(obj, propName, func) {
Object.defineProperty(obj, propName, {
get: function () {
// TODO: memoization
return func.bind(this);
},
value: func
});
}
However, you can’t have both a getter and a value for a property. If calling a method was different from reading the property and invoking the returned reference then it could be done. Then we would have:
someObj.foo // get
someObj.foo = bar // set
someObj.foo(...) // invoke
That means the property descriptor would look as follows:
function myDefineMethod(obj, propName, func) {
Object.defineProperty(obj, propName, {
get: function () {
// TODO: memoization
return func.bind(this);
},
invoke: func
});
}
This might clash with the proxy protocol and might thus not be a good idea.
I wonder if, with the concise method notation for literals (and possibly class declarations), one couldn’t introduce three modes of accessing a property: Read (getter), write (setter) and call (call interceptor?).
thisI have no idea how this would fit into the current semantics, so it might be a silly idea, but it would eliminate a common source of bugs.