2012/11/13 David Bruant bruan...@gmail.com
For the particular case you've written, when going for
hasOwnProperty.call or the in operator, the JS engine knows it needs to
output a boolean, so it can rewrite (or contextually compile) your trap
last line as e===undefined (since undefined is
2012/11/13 Erik Arvidsson erik.arvids...@gmail.com
On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem tomvc...@gmail.comwrote:
So, my proposal: let's revert the fundamental traps of Handler to become
abstract methods again. This forces subclasses of Handler to provide all
fundamentals at once,
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 13, 2012, at 12:25 PM, Tom Van Cutsem wrote:
It's dawning on me that the main reason I dislike adding flags to the
fundamental traps is that it breaks the 1-to-1 symmetry with the operations
that they intercept:
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
Regardless, my main concern isn't this optimization issue, but instead a
concern about it being too easy to inadvertently define an internally
inconsistent Proxy.
Indeed. So let's get back to alternative solutions to avoid the
inconsistent
On 14 November 2012 09:30, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/13 David Bruant bruan...@gmail.com
For the particular case you've written, when going for hasOwnProperty.call
or the in operator, the JS engine knows it needs to output a boolean, so it
can rewrite (or contextually
Tom Van Cutsem wrote:
At its core, this footgun is not specific to Javascript proxies:
it's an old problem in OO frameworks in general, whose documentation
may state: if you subclass class C, and you override method foo,
make sure you also override method bar consistently!. I'm sure
you've
Nb: A limit is consistent with String.prototype.split which has an optional
limit in the range [0:4294967295] to avoid excessiveness.
(no great insight, but interesting?)
-
From: Alex Vincent
Sent: Tuesday, November 13, 2012 2:07 AM
To: es-discuss@mozilla.org
Subject:
Le 14/11/2012 07:35, Brendan Eich a écrit :
Also Tom's point about precision counts, independent of allocations. A
hasOwn test in the MOP should not call the same thing that
Object.getOwnPropertyDescriptor calls, if we can help it
I don't think it's possible. This thread started with the
I don't know when tasks.js will be usable (ie generators supported)
but probably it's a very good solution to solve all the async (and
resync) issues I had doing https://github.com/Ayms/node-Tor where
unexpected and unpredictable things as well as performances reasons
forced me to use
If the second argument is optional, it's possible to have both one-arg and
two-arg styles in the same API.
What do people think about this idea?
Maybe - minimalism served the class proposal quite well. It might be a
good strategy here, too.
Here's what I'm thinking:
// Creates a new
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where you
have “future” and you avoid needless confusion and conflict.
This isn’t Scala; we have existing terminology for exactly these concepts. Just
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where
you have “future” and you avoid needless confusion and conflict.
I prefer to find the optimal solution first and then consider migration
costs
From: Kevin Smith [khs4...@gmail.com]
Sent: Wednesday, November 14, 2012 11:41
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where
you have “future” and you avoid needless confusion and conflict.
On Nov 14, 2012, at 1:22 AM, Tom Van Cutsem wrote:
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 13, 2012, at 12:25 PM, Tom Van Cutsem wrote:
It's dawning on me that the main reason I dislike adding flags to the
fundamental traps is that it breaks the 1-to-1 symmetry with the
You might want to check out Norbert's proposal [1]
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
[1]
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html
On Nov 14, 2012, at 1:25 AM, Tom Van Cutsem wrote:
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
Regardless, my main concern isn't this optimization issue, but instead a
concern about it being too easy to inadvertently define an internally
inconsistent Proxy.
Indeed. So let's get
On Nov 13, 2012, at 10:35 PM, Brendan Eich wrote:
Erik Arvidsson wrote:
On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
So, my proposal: let's revert the fundamental traps of Handler to
become abstract methods again. This forces
I think you meant optimally colored bikeshed, but OK.
Ouch : )
Names are important. Especially when it comes to something as potentially
confusing as promises and futures.
- Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Nov 14, 2012 at 11:25 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where
you have “future” and you avoid needless confusion and
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith khs4...@gmail.com wrote:
I think you meant optimally colored bikeshed, but OK.
Ouch : )
Names are important. Especially when it comes to something as potentially
confusing as promises and futures.
I agree that names are important.
1) First
On 14 November 2012 18:41, Mark S. Miller erig...@google.com wrote:
Either way, Scala's
unfortunate choice clearly violates this history in a confusing manner, so
I'd classify it as #4. Let's not repeat Scala's mistake.
Just to reiterate, it's not just Scala, but more importantly also C++,
On Wed, Nov 14, 2012 at 12:48 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Nov 14, 2012 at 9:28 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Nov 14, 2012 at 11:25 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Why go purposefully against the existing
David Bruant wrote:
What's the error forwarding/handling story for tasks?
That's the real beauty: try-catch and yield with thrown exceptions from
resumed generators compose just as you'd expect.
/be
___
es-discuss mailing list
I personally think Scala made a good choice, because most of the time all
we are concerned with is the future. And we can talk about futures
independently from invoking the promise analogy. I think the promise
analogy is great, but in my opinion it can be a little bit tricky for
people to pick
2012/11/14 Andreas Rossberg rossb...@google.com
On 14 November 2012 18:41, Mark S. Miller erig...@google.com wrote:
Either way, Scala's
unfortunate choice clearly violates this history in a confusing manner,
so
I'd classify it as #4. Let's not repeat Scala's mistake.
Just to reiterate,
On Fri, Nov 2, 2012 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
There is no verifiable formal contract. But there can be an informal
contract. In my experience, it is very important when using a dynamic
language to recognize and try to support such informal contracts.
Well,
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 14, 2012, at 1:22 AM, Tom Van Cutsem wrote:
Given approach 1) she can look at the full list of traps (e.g. the list at
the top of http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies)
and quickly figure out that she must
2012/11/14 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 14, 2012, at 1:25 AM, Tom Van Cutsem wrote:
- You don't need to subclass Handler if you are building proxy
abstractions that only do before/after/around-style wrapping of a target
object. Even if you implement only some of the traps
Thanks for the ref to Norbert's proposal.
(I have been interested in i18n since writing an international telephony
switch control system in 1987.)
Norbert's proposal has much interesting info about formats, locales,
case-mapping much else, but says little about the String.* functions or
how
29 matches
Mail list logo
