On 26.10.2010 11:41, Tom Van Cutsem wrote:
2010/10/25 Brendan Eich <[email protected] <mailto:[email protected]>>
On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote:
2010/10/20 Dmitry A. Soshnikov <[email protected]
<mailto:[email protected]>>
Anyway, is there an alternative how [[HasProperty]] can work
correctly? I just though, that it's called by the "has" hook
of a handler, which in turn can "lie" of course (i.e. return
true when a property does not exist -- in such a case,
noSuchMethod won't be called).
I think Dmitry is right: calling [[HasProperty]] on a proxy
object should trigger its "has()" trap in the normal way, which
should work with double lifting.
IIRC the problem is a meta level-shifter wants to implement just
one trap, get in the absence of invoke. Would integration of
noSuchMethod using has ("object detection") break this?
No, this would be the case if [[HasProperty]] were called directly on
the handler object. However, calling [[HasProperty]] on the proxy
object will still query the handler for its "has" trap using the
handler's [[Get]] internal method, i.e. it won't feature-test the
handler object directly.
Anyway, the general issue before us is a least this choice:
* Either we stick with the current more minimal design, which
besides being smaller also serves the goal of avoiding a
method_missing (honey-)trap that tends to break JS's
functional-programming,
methods-can-be-extracted-and-passed-around-as-funargs-for-later-apply-usage,
design win.
* Or we add noSuchMethod and satisfy the "just give me a new trap,
I'll either use it well in method-only programs or make it work
with has/get/etc." use-cases of Dmitry and others.
To reiterate something lest people get angry, this is not an easy
trade, and I don't see anyone being rigid. It's simply a design
decision we have to make one way or another.
Going into the process in TC39, as I noted previously, I did my
best to argue for noSuchMethod.
Damn, where have I been at that moment? ;)
But having now written some proxy code, I'm much less concerned
about the overhead of making a coherent proxy that has methods you
can extract. That leaves me thinking the case of "just give me the
method_missing trap" use-case is not worth the added weight. And
Tom and Mark agree, and they are the champions of this proposal.
That's a good summary.
Yep, the summary is good, but as was mentioned -- if to forget about
noSuchMethod and to move it to the minor goal, then the major one -- is
solving the issues related with current imitation of noSuchMethod (via
get+fn). The most inconvenient issue, is that in this implementation
always a function is returned (that breaks checks such as if (!foo.bar)
foo.bar = {} -- and actually breaks principles of an abstraction -- a
designer of the `foo` forces a user of the `foo` to have a very strange
situation -- always a function is returned for every non-existing stuff;
thus, the user, by principle of the abstraction shouldn't know that he
deals with a proxied object). Unfortunately, this issue is unresolvable,
since to have virtual functional objects (being able to pass them as
funargs e.g.) it's required to return always a function for every
non-existing property. Plus, inconvinience with caching/invalidationg
the cache to keep the === invariant.
So, from this viewpoint, this additional noSuchMethod hook seems just a
logical _consequence_ of trying to avoid these issues (but not a desire
to exactly have it).
So can we let this stand for now and see how deployed Proxies in
Firefox 4, beat on by real users who are willing to try them as
spec'ed without noSuchMethod, fly with developers? That is one
pretty good (albeit slow) way to get new data and insights.
I think this is a good choice in going forward. Since noSuchMethod can
be an optional trap, it could be added later without breaking existing
handlers that do not define it. The only issue we can run into is that
some handler code out there already defines a noSuchMethod trap and
means it to do something completely different than what a future spec.
has in mind.
Yes, possibly it's a good choice, it really seems just a design decision
("either with, or without it"). So a real users feedback will be
possibly a better reason. Let it be. The only thing I'm also worried is
that it won't become too late.
P.S.: for fairness, possibly it's needed to mention on strawman proxy
page, that such provided imitation of noSuchMethod has know lacks and
that users should use it carefully.
Thanks,
Dmitry.
Cheers,
Tom
Or we could keep arguing here, but I think we've gone around the
same block more than once!
/be
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
