Re: Proxies: get+fn vs. invoke
On 26.10.2010 11:41, Tom Van Cutsem wrote:
2010/10/25 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote:
2010/10/20 Dmitry A. Soshnikov dmitry.soshni...@gmail.com
mailto:dmitry.soshni...@gmail.com
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
es-discuss@mozilla.org
Single argument Array.prototype.splice
ES3 and 5 specify Array.prototype.splice such that [1,2,3].splice(1) means the same thing as [1,2,3].splice(1,0) Mozilla documents (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/splice) an extended form of splice: array.splice(index, [howMany, [element1][, ..., elementN]]); // SpiderMonkey extension where [1,2,3].splice(1) essentially means [1,2,3].splice(1, [1,2,3].length) Most other browsers also seem to support this extensions. Was it an oversight that ES5 was not updated to include support for this extended behavior? Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies: get+fn vs. invoke
On 27.10.2010 21:15, Brendan Eich wrote:
On Oct 27, 2010, at 9:07 AM, Tom Van Cutsem wrote:
With the risk of going round the block again... ;-)
Last time for sure. :-|
Acknowledged ;|
I agree with your premises, namely that:
a) `if (!foo.bar) foo.bar = {}` is a common pattern to patch up objects that
don't know how to deal with `bar` requests
b) a proxy that pretends to have all possible properties can't be patched up
using this pattern
But I don't buy your conclusion, which is that a + b implies that proxies are somehow
broken. If the proxy says I know how to handle `bar` properties, then the
client doesn't need to patch up the proxy by adding a `bar` property. Your patch-up
pattern will work perfectly fine with proxies that don't pretend to have a `foo` property.
There are good reasons for why proxy writers may want to distinguish get from
invoke (for example, because invoke doesn't require caching the function
returned by `get`),
(that was a reason I gave back when I was arguing for an invoke trap, yes.)
but IMHO this patch-up pattern is not one of them.
Agreed, it is not one of them.
Dmitry, you are hypothesizing a proxy whose handler lazily creates all trapped
properties with some non-falsy initial value.
But no one is dictating such a proxy handler implementation, it is broken as
Tom points out but due to its own straw-design mistake (not due to anything
inherent in Proxies), and in reality it's hard to write such a proxy.
In reality, programmers won't write handlers that trap any property name and return a
useful (non-empty or not-constant-for-many-names) function value. My lazy method cloner,
e.g., clones only methods found in (whether own or not) the given
clone-parent object. It can't proxy a method for a property not in that object.
There is no object detection pattern that works for a silly proxy that
returns, e.g., (function(){}), for all property has and get traps. Such a proxy is doing
what you coded it to do, however broken or absurd. It is not the fault of the
harmony:proxies proposal, or in any way due to the lack of noSuchMethod traps, that this
could happen.
So really, this is a straw-man fallacy. We knock it down, but Proxies still
stand. One can, after all, write silly or broken toString implementations in JS
today, and patch them into Object.prototype even. This is a feature, not a bug.
Object detection, BTW, is not metaprogramming at all, IMHO. So I don't agree that if (!foo.bar)
foo.bar = ... is a pattern for trapping missing properties. It is imperative code in
the base-level language. You have to write it in a certain place (or places) in the control flow
graph. If you want something that runs for a given foo when accessing bar, via a
proxy-like API, then we are talking about real behavioral intercession metaprogramming.
So I don't buy Dmitry's argument that noSuchMethod somehow complements or
completes the existing object detection pattern, but for call expressions --
the method_missing Ruby feature. It is not complementary, or even on the same
meta-level. And really, the primal issue is whether invoke-only methods are a
desirable pattern.
The reason I gave up noSuchMethod was that you can't make a coherent object
with extractable methods-as-funargs without the full suite in the current
harmony:proxies proposal, if all you have is noSuchMethod. But given the full
suite in the current proposal, if you lack noSuchMethod, you can still emulate
host and native objects. There are no invoke-only methods in ECMA-262, and the
ones in ECMA-357 are considered design flaws, corrected (albeit with a clunky
workaround, function::) in SpiderMonkey's E4X implementation.
So my final answer remains: invoke-only methods are an anti-pattern.
Ok, still I have no doubt Dmitry will argue: a trap for invoke-only methods is
desirable on some basis, by some developers. It may be among a large number of
developers, but we've heard only from a few (and with too many trips around the
same block).
In any event, without more going 'round the same block over and over, we'll
have to see how the more minimal, current harmony:proxies design plays out with
a wider audience of developers who can actually play with it in Firefox 4.
(I still don't see how invoke-only methods work with all the
partial-applying/currying JS libraries out there today (Prototype, JQuery,
etc.), but perhaps there is a bright line between the functional-programming
style of those libraries, and the intended noSuchMethod invoke-only methods.)
Yes, all this has already been said before in this thread, and the
reason to have alive funargs instead of phantoms is a sound reason.
Again, what I wanted -- is to catch all subtle cases, to see whether the
API is consistent and to find the solutions for inconsistency. Nobody
wants just to argue. So, let's conclude at this step. As said before, if
later this additional noSuchMethod will be strongly required by JS
Re: Single argument Array.prototype.splice
On Oct 27, 2010, at 10:37 AM, Allen Wirfs-Brock wrote: ES3 and 5 specify Array.prototype.splice such that [1,2,3].splice(1) means the same thing as [1,2,3].splice(1,0) Mozilla documents (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/splice) an extended form of splice: array.splice(index, [howMany, [element1][, ..., elementN]]); // SpiderMonkey extension where [1,2,3].splice(1) essentially means [1,2,3].splice(1, [1,2,3].length) Most other browsers also seem to support this extensions. Was it an oversight that ES5 was not updated to include support for this extended behavior? An oversight from the ES3 era, carried forward into ES5 without review that I can recall. Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony? I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up. /be Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New topic regarding Proxies: intercession for ===
On 2010-10-27, at 17:09, Brendan Eich wrote: JS will never be as simple as Self, but with proxies and value types based on them, it seems we might have get very close to the right answer to David's question. 2p. from the Dylan POV: Dylan only had equality and identity (thinking Lisp had just way too many equivalences). Dylan's MOP let you override (the equivalent of) `new` and `==`, but not `===`. If you wanted value objects that were indistinguishable, you wrote a `new` implementation that always returned the identical object for parameters that would otherwise create `==` values (using a weak-key table). If you only cared about equality, you wrote a `==` method that implemented your equality test. You chose based on whether you expected to do more constructing or more comparing. Is a proxy enough of a power tool that you just have to warn the user they must know what they are doing to use it? I.e., if you override the MOP in some inconsistent way, it's not our fault? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
15.3.4.3 Function.prototype.apply (thisArg, argArray)
ES5 does some changes in Function.prototype.apply. It allows generic array-like object for a second argument of `apply' method. | 6. Let n be ToUint32(len). | 7. If n is not equal to ToNumber(len), then throw a TypeError exception. Isn't better to throws a RangeError instead of TypeError? Is this a typo or it must be a observable behavior of `apply'? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: strict mode bugs on amazon.com
On 10/27/10 10:26 PM, Oliver Hunt wrote: We just got a bug report on webkit saying that http://www.amazon.com/gp/goldbox/ref=cs_top_nav_gb27 Fwiw, this was mentioned on this list in the past... See https://bugzilla.mozilla.org/show_bug.cgi?id=579119 and https://mail.mozilla.org/pipermail/es-discuss/2010-September/011769.html which references that bug. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 15.3.4.3 Function.prototype.apply (thisArg, argArray)
Check out the ES5 erratum -- steps 5 and 7 have been removed. http://wiki.ecmascript.org/doku.php Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES5 errata submission
On 10/27/2010 07:24 PM, Michael Dyck wrote: If I find bugs in the ECMAScript Language spec (bugs that aren't already reflected in the July 31st Errata doc), what should I do? Post 'em here, that's what everyone else has done. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New topic regarding Proxies: intercession for ===
On Oct 27, 2010, at 4:12 PM, P T Withington wrote: On 2010-10-27, at 17:09, Brendan Eich wrote: JS will never be as simple as Self, but with proxies and value types based on them, it seems we might have get very close to the right answer to David's question. 2p. from the Dylan POV: Dylan only had equality and identity (thinking Lisp had just way too many equivalences). Dylan's MOP let you override (the equivalent of) `new` and `==`, but not `===`. If you wanted value objects that were indistinguishable, you wrote a `new` implementation that always returned the identical object for parameters that would otherwise create `==` values (using a weak-key table). If you only cared about equality, you wrote a `==` method that implemented your equality test. You chose based on whether you expected to do more constructing or more comparing. We talked about this during the decimal discussions in past TC39 meetings, but hash-cons'ing decimal non-literals, esp. intermediate results in arithmetic expression evaluations, is too expensive for hardcore numerical performance folks. If value types are frozen all the way down and they bottom out soon enough, then comparing references or (if those do not match) referents, byte-wise and deeply, should be enough for default ===. It won't handle -0m === 0m or 0m/0m !== 0m/0m (the NaN in decimal !== itself). At one time we thought we could deviate from IEEE 754r on those fine points. Probably === needs to be meta-programmable to capture all the possibilities. Is a proxy enough of a power tool that you just have to warn the user they must know what they are doing to use it? I.e., if you override the MOP in some inconsistent way, it's not our fault? Yes, as The Art of the Meta-Object Protocol makes clear, you can't avoid some sharp edges on these power tools. This is not an excuse for avoidable unsafety of course. As noted, overriding Object.prototype.toString and other such built-ins is a bad idea too. Proxies, like host objects in real browsers, can produce nonsense answers, but ES5 tightens up the language about what is legal per-spec. Proxies don't introduce overt lack of safety, but they do mean code that thought a[i] was never running a function (a handler trap) might have its expectations violated. But getters and setters already rocked this boat. This is why for-in should be metaprogrammable, or really: objecting to for-in being programmable by a Proxy's handler iterate trap is objecting too late and selectively, when the get and set horses (ES3R, or ES5 now), and the rest of the harmony:proxies trap-horses (12 in total so far, excluding iterate), have already left the barn. Proxies are power tools. Client code that may wind up using them, even old code written before their advent, will expect them to behave like native objects (or good host objects). This puts pressure on proxy implementors, and the JS library and client-code ecosystem will have to sort good from bad proxy implementations. TC39 certainly can't guarantee no bad proxies are written, except by renouncing metaprogramming -- which we have not done in ES5 (or the ES3R ES3 + reality that ES5 drew on), and will not do (in Harmony, per plans on the wiki). Renunciation in favor of the safety of pre-1999 JS (no getters or setters) so leaves us with only the browser implementors and their host objects as the privileged mess-makers. From a purely Machiavellian point of view, we want to level this playing field. It's a scary world, but you're better off with user-level metaprogramming in JS, compared to a world of only kernel-level metaprogramming in typically C++ host object codebases. At least, I think that's TC39's position. It certainly is mine. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES5 errata submission
[+es5-discuss] On Wed, Oct 27, 2010 at 7:24 PM, Michael Dyck jmd...@ibiblio.org wrote: If I find bugs in the ECMAScript Language spec (bugs that aren't already reflected in the July 31st Errata doc), what should I do? Oddly, the spec itself doesn't tell me, nor does ECMA's web page for the spec, nor its web page for TC39. The only place where I found a solicitation for feedback is http://www.ecmascript.org/community.php . It points to the Harmony wiki, but that appears to be readonly for outsiders. Ditto the Trac db, although there's a button to register; but it seems kind of inactive (only 7 events in the last year). So I'm asking here: what's the best means (and form) for giving feedback on the ES5 spec to TC39? This lack of explanation is a serious problem. Thanks for bringing it to our attention. The best place to post is to es5-disc...@mozilla.org so suggested errata can easily be found. Often such messages are addressed to es-discuss as well, especially if the issue is likely to be of general interest. -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES5 errata submission
On Wed, Oct 27, 2010 at 7:24 PM, Michael Dyck jmd...@ibiblio.org wrote: If I find bugs in the ECMAScript Language spec (bugs that aren't already reflected in the July 31st Errata doc), what should I do? Oddly, the spec itself doesn't tell me, nor does ECMA's web page for the spec, nor its web page for TC39. The only place where I found a solicitation for feedback is http://www.ecmascript.org/community.php . It points to the Harmony wiki, but that appears to be readonly for outsiders. I've added a link at the obvious place on the EcmaScript wiki to the es5-discuss list. Ditto the Trac db, although there's a button to register; but it seems kind of inactive (only 7 events in the last year). So I'm asking here: what's the best means (and form) for giving feedback on the ES5 spec to TC39? -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
