On Thu, Jan 20, 2011 at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
This is the killer for me. Do not want to change === and require all-paths
runtime test coverage to migrate code into Harmony.
You're bang-on about the end user impact of this change - I would not be
able to migrate any
Hi David, I'm forwarding your message to es-discuss as it has no direct
relevance to ES5 per se.
All, please reply only on es-discuss.
-- Forwarded message --
From: David Bruant bru...@enseirb-matmeca.fr
Date: Fri, Jan 21, 2011 at 3:08 AM
Subject: On ES Harmony proxies
On Fri, Jan 21, 2011 at 6:09 AM, Wes Garland w...@page.ca wrote:
On Thu, Jan 20, 2011 at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
This is the killer for me. Do not want to change === and require all-paths
runtime test coverage to migrate code into Harmony.
You're bang-on about the
Hi David,
What does exactly not be trapped mean? If you define a property on a proxy
object, the defineProperty trap of the handler is the only method with which
that operation can succeed. If defineProperty doesn't exist you want us to just
ignore the operation?
I think this approach has
I for one am very much against setting inferValues to true by default.
That's just obfuscating i18n bugs, and I think we should design our APIs
so that it's easy to get it right. Shooting yourself in the foot should
be hard, if at all possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
We have previously discussed adding standard handlers to the specification,
i.e. an NoopHandler and a ForwardingHandler.
Yes, and Tom and Mark have been working on this and making good progress. They
have a forwarding handler mostly worked out, which we discussed yesterday at
the
I would actually rather not have it be a construction argument, because it
is easier for people to make mistakes that way.
When I look this over, there are relatively few fields that need this. So
what about having API like:
// get an explicitly-set region, or null if there was no region
IMO that’s going overboard in the other direction ☺ It’d be nice to find some
middle ground.
Sometimes inferring can be very bad. Sometimes it can be very good. The
problem isn’t that one is “right” or “wrong” for all apps, but rather that it
might be simple for developers to accidentally
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up that
implements just the other traps you want to implement, and let the others fail
soft.
Dave
___
es-discuss mailing list
The problem I see is that if I hand you a LocaleInfo, and there is only one
API to get the region, then it (in your words) **is easy** to accidentally
make the wrong choice, or not realize they need to make a choice.
- x.region may be an explicit value or may be computed: I have to call
I think a reasonable approach is to tag the localeinfo itself as “please infer”
or “do not infer”. Then I don’t have to use special code in a helper API for a
caller that wants one behavior or the other. And it’s reasonably trivial for
me to collect the information. Presumably I could even
Not sure; I'll think about it. Though abstracting
Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
convenience.
Dave
Mark S. Miller erig...@google.com wrote:
On Fri, Jan 21, 2011 at 2:45 PM, David Herman dher...@mozilla.com
wrote:
Should we have a no-op or sink standard
12 matches
Mail list logo
