__noSuchMethod__ and direct proxies
dmitry.soshnikov at gmail.com
Mon Dec 5 04:36:10 PST 2011
On Mon, Dec 5, 2011 at 4:05 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2011/12/5 Dmitry Soshnikov <dmitry.soshnikov at gmail.com>
>> Just a note. Seems we're going to back to the unstratified API? When long
>> time ago in that long thread (
>> with `isCall' flag for `get', I was showing a similar example with
>> `__noSuchProperty__' and `__noSuchMethod__' (
>> you were against such __magicAssignments__ to objects. Though, in my case
>> those were proxies, created by alternative protocol: `Object.new'.
> Just to make sure I am not misunderstood: no, "we" are not going back to
> the unstratified API!
> __noSuchMethod__ remains as unstratified as it ever was.
You mean you don't propose to standardize it or sort of? I.e. it's just a
"library" variant of how one can implement `__noSuchMethod__'? Oh, then
it's OK, since there can be many own implementations in particular
> I maintain that the stratified Proxy API is safer than __noSuchMethod__.
Yup, especially if it can be achieved also with convenient "assignments",
but still noSuchMethod will be meta-property and won't exist on the object (
> The above was simply an answer to the question as to whether proxies might
> provide a way to support __noSuchMethod__ without turning your object into
> a proxy.
I see, OK ;) It's a good variant of implementation.
> They do, but that doesn't make __noSuchMethod__ any more principled.
> So, FTR, I still prefer using a proxy with a |get| trap over a
> __noSuchMethod__ hook ;-)
k, got it
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss