On 17.12.2011 18:08, Andrea Giammarchi wrote:
Dmitry, addressing a trap fallback is not a good idea plus the average
JS coder rarely does it ... said that, the moment you are using a
method you already know this exists so you already know the
documentation ( or part of it ) so I don't see much hurt there.
That's it. In designing a language it's better not to build the
decisions based on "rarely" reasons. Yes, of course we should consider
percentage of usage of this or that feature, so basically it's good to
analyze whether is feature is "rare" or "frequent". But in general, we
can't predict 100% will the method be used in some different ways or not
-- especially if the user _may_ use it in this way in JS.
Once again, in PHP and others it's much easier to implement things like
`__call', etc (until 5.3 it even didn't have closures). In languages
like Ruby it's also easier to implement it, since `foo.bar' is _already
a method call_ (or sending a message). There is only method calls in
Ruby, there are no properties. This is why `method_missing' is logical
there.
In JS, as well as in Python, there is no method calls, but there is
getting property values and already after that provide some operations
on them (in case if the value of the property is a function, you may
call it). This is, by the way, why Python also doesn't support separated
`__nomethod__' magic name. In Python, as well as in JS proxies, you have
to return an "activator" function from `__getattr__'.
Moreover, the addressing problem is common for all self bound methods
and the usage of call and apply
var o {getStuff:function(){return o.stuff}};
// or o.getStuff = o.getStuff.bind(o);
Whoever gonna address "getStuff" will have unexpected results with any
context different from o so, again, whoever is using a method must
know at least basis of the methods.
Yes, this is fair enough. If the user extracts the function for further
applies, she should know whether a function is generic to be able apply
it for different `this' values. OTOH, she can do this only for
optimizations. `toString.call' is faster than
`Object.prototype.toString.call', so she just saves it to the variable
and calls.
Methods that fallbacks through a trap as noSuchMethod is should not be
documented as methods because inexistent, these should rather be
documented under the "magic behavior" explaining in the very first how
it works and why.
Yes, as I said, I see this way as the only existing to solve the issue
-- to mention in the documentation, that methods such as
`find_by_<fieldName>' are magic and that we can't extract them or apply
in different contexts. If this is acceptable, then this is OK. Then we
force user to know it and to follow this rule. OTOH, it may be good.
I don't see many troubles into an invoke-only fallback, I see troubles
or limits without this possibility.
The proxy trap is not even an option to me, not to simulate proper
noSuchMethod behavior where again, typeof o.nonExistentMethod should
be "undefined", accordingly with __proto__ and getter over that property.
Yep, this is also true, and I mentioned it several times in that long
thread.
Are these missing? Cool, there is no such method or property with that
name so "undefined" and nothing else.
Ideally, we could find a better way to define objects that implements
__noSuchMethod__ interface so that developers can be aware in advance
of potential mistakes
This is what nearly Tom proposes with inheriting a special (proxy)
object. I.e. some object which inherit it will have this _unstratified_
noSuchMethod, placed directly on the object (still via proxies, with all
broken invariants applied), and some do not. OTOH, he also proposed to
be `Object.prototype' as such a proxy. It can be a good idea, though
will decrease efficiency.
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
