Le 20/06/2013 18:08, Mark Miller a écrit :
On Thu, Jun 20, 2013 at 7:50 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 20/06/2013 14:55, Forbes Lindesay a écrit :
I’ve been answering quite a few questions about promises on stack
overflow lately
Le 18/06/2013 23:49, Chad Austin a écrit :
Hi all,
Hoping to proactively polyfill likely parts of upcoming standards, I
am adding an implementation of DOM promises to IMVU's base JavaScript
library.
Why was done() removed from the draft spec? Rename Futures per TC39
discussion. Drop
Le 15/06/2013 11:18, Bruno Jouhier a écrit :
A generator object represents a computation which has been suspended.
We have an API to resume this computation (next/throw). What's missing
is an API to get information about this suspended computation (which
function, where in the source).
As an
Le 14/06/2013 02:37, Mark S. Miller a écrit :
Other things being equal, or even close, I am always in favor of specs
being more deterministic.
Even with this pinned down, we should still allow implementations to
switch among different algorithms based on the size of the array, the
cache
Le 14/06/2013 09:55, Andreas Rossberg a écrit :
On 14 June 2013 09:50, David Bruant bruan...@gmail.com wrote:
And this particular behavior might be standardizable without a loss (even
with a gain), because:
1) a sort algorithm only needs all the array values once at least once
(serie of [[Get
Le 14/06/2013 16:56, Bruno Jouhier a écrit :
I'm using ES6 generators to implement a little async/await library and
I'm quite pleased with the result so far but I'm lacking one API: a
function to get stack information from a generator object. Ideally it
would return the name of the current
Le 13/06/2013 21:16, Kevin Gadd a écrit :
I have read the ES specs multiple times, and still accidentally
shipped an application that was broken by Array.sort's default
behavior in the wild. I know other people who have had the same
issues, and people who have read the spec and don't happen to
Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
I think your analysis is mostly right: if we want to make e.g.
Date.prototype.getTime.call(proxy) work, then the easiest way to fit
that into the current design would be to add Date-specific traps (and
Map-specific, Set-specific, Regexp-specific,
Le 09/06/2013 12:50, David Bruant a écrit :
Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
For full transparency across isolated object graphs, I think
membranes are still the way to go.
I don't understand that part. A membrane (with shadow targets?) will
have the same problem as a proxy alone
Le 08/06/2013 20:22, Axel Rauschmayer a écrit :
It's difficult to do that if you want your constructors to remain
subtypable. Is the following the best we can do? A constructor can
only freeze if it is the first constructor that is invoked.
function Point(x, y) {
this.x = x;
Le 07/06/2013 07:31, Jason Orendorff a écrit :
On Thu, Jun 6, 2013 at 10:54 AM, gaz Heyes gazhe...@gmail.com
mailto:gazhe...@gmail.com wrote:
It's syntax is based on JavaScript but crippled for no reason
other than to follow a outdated specification. It's so frustrating
to be at
Le 07/06/2013 06:41, Kevin Smith a écrit :
+?
Get off my lawn! comment (I will tag in and tag Doug out of the
grumpy old men smackdown ring): you kids stop fiddling with JSON.
It needs fixing like it needs a hole in the head.
Comment syntax sure would be nice though : P
As
Le 02/06/2013 09:46, Rick Waldron a écrit :
4.4 Proxies
Proxy Invoke Trap and wrong |this|-binding on built-in methods
AWB: with current default behavior of “get”, “Caretaker” will break on
built-ins such as Date, because the |this| binding is by default set
to the proxy, so the Date
Le 07/06/2013 13:15, Brandon Benvie a écrit :
On 6/7/2013 12:53 PM, David Bruant wrote:
Le 02/06/2013 09:46, Rick Waldron a écrit :
4.4 Proxies
Proxy Invoke Trap and wrong |this|-binding on built-in methods
AWB: with current default behavior of get, Caretaker will break
on built-ins
Hi,
Should the use strict directive work inside an arrow function?
Currently, for () = {'use strict'; return typeof this } returns
'object' in Firefox (it's the global object). Is it the intended behavior?
David
___
es-discuss mailing list
Le 06/06/2013 12:49, David Bruant a écrit :
Hi,
Should the use strict directive work inside an arrow function?
Currently, for () = {'use strict'; return typeof this } returns
'object' in Firefox (it's the global object). Is it the intended behavior?
Yeah... Don't bother answering. lexical
Le 04/06/2013 06:57, Andy Earnshaw a écrit :
Something that occurred to me today is that we have methods for
locking down objects in different ways except for preventing changes
to existing properties. We have:
- Object.seal to prevent new properties being added or existing
properties
Le 04/06/2013 11:24, Andy Earnshaw a écrit :
I'm not sure I understand what you're saying here. Do you want to
return the same or a different object? For sure, your caller will
know if you returned a different object (because it can compare
the argument and the return value)
Le 01/06/2013 23:14, Petter Envall a écrit :
Re In this language, I'm not aware of other languages where you
need to concatenate code. It has become a good practice for perf
on the web as a workaround of HTTP 1.x limitations.
HTTP 2 promises that with multiplexing, script
Le 01/06/2013 16:52, Jorge a écrit :
On 02/06/2013, at 01:22, Brandon Benvie wrote:
On 6/1/2013 3:44 PM, Jorge wrote:
But they're not fully interchangeable, for example I can exit a function at any
point with a return, but can I exit a block at any point with a break or
something?
Le 01/06/2013 21:10, Petter Envall a écrit :
2013/6/2 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 01/06/2013 16:52, Jorge a écrit :
On 02/06/2013, at 01:22, Brandon Benvie wrote:
On 6/1/2013 3:44 PM, Jorge wrote:
But they're not fully
Hi Till,
I believe Boris Zbarski touched on this recently at
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0428.html
(I haven't read the full thread, so can't tell what the conclusion were,
but it's probably worth checking out)
David
Le 31/05/2013 04:33, Till
Le 22/05/2013 19:02, Tab Atkins Jr. a écrit :
On Wed, May 22, 2013 at 9:44 AM, Brendan Eich bren...@mozilla.com wrote:
NodeList extends Array now but is not literally Array plus hooks. Same for Map
and the quite different thing you're specifying.
NodeList is an interesting case, actually.
Le 21/05/2013 04:06, Tab Atkins Jr. a écrit :
For the CSS Variables spec I need to define an object with arbitrary
string keys, with the initial set determined by the custom properties
set in the style rule, and on modification I need to coerce the
provided key to a string, and then go mutate
Hi,
David Bruant wrote:
Le 21/05/2013 04:06, Tab Atkins Jr. a écrit :
(One way to do this today is to subclass Map and provide my own
get/set/etc. functions, but I need to override a potentially-open set
(anything that doesn't directly lean on my overridden functions), and
it doesn't
Le 21/05/2013 13:19, Brendan Eich a écrit :
David Bruant wrote:
This description (arbitrary string keys, bidirectional link with
style rule) suggests that you want a proxy (canonical values are in
the style rule, the proxy is just a façade with a bit of
validation/coercion logic). That's
Le 09/05/2013 18:14, Brendan Eich a écrit :
Andreas Rossberg wrote:
But not __proto__ -- dream on if you think that is going away any
time soon!
I was thinking about V8 embedders other than browsers who could toggle
that flag.
Node won't, if I recall correctly. Any other embeddings of
Le 07/05/2013 18:30, Andrea Giammarchi a écrit :
You did not answer my question Mark: what is the role of TC39, embrace
whatever non-standard crossbrowser thing or filter ideas proposing
better alternatives/solutions when necessary in order to have a solid
foundation instead of having
Le 08/05/2013 16:46, Andreas Rossberg a écrit :
On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Let's keep
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
consistency should win.
JavaScript implementations in new or existing eco systems that are not
Hi,
The latest rumors [1] suggest that __defineGetter__ will be in IE11.
David
[1]
http://fremycompany.com/BG/2013/Internet-Explorer-11-9385-new-features-771/
___
es-discuss mailing list
es-discuss@mozilla.org
Le 02/05/2013 08:51, Tom Van Cutsem a écrit :
2013/5/1 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
If anything, I would recommend to move away from the initial proxy
design for Caja, because the harmony:proxies API is meant to never
see light in the spec (and should
Le 01/05/2013 22:26, Kevin Reid a écrit :
In Caja we have several uses for Proxies, some of which involve
reimplementing or modifying the Proxy API.
Out of curiosity, how are you modifying it? for which use case?
We are currently following
the original harmony:proxies (rather than direct or
Le 29/04/2013 18:09, Brendan Eich a écrit :
Users want class-private (and module-private?) syntax.
I'm not up-to-date on the module work, but last I looked at it, module
private is everything except what is explicitly exported, no? (which is
a good thing, I believe)
David
Le 21/04/2013 19:22, Brendan Eich a écrit :
At JQueryUK, I threw up a sketch in slides based on
http://wiki.ecmascript.org/doku.php?id=strawman:relationships:
|class SkinnedMesh extends THREE.Mesh{
private identityMatrix,
bones,
boneMatrices;
constructor(geometry,
Le 29/04/2013 00:32, Mark S. Miller a écrit :
On Sun, Apr 28, 2013 at 2:33 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 21/04/2013 19:22, Brendan Eich a écrit :
At JQueryUK, I threw up a sketch in slides based on
http://wiki.ecmascript.org
Le 27/04/2013 11:10, BelleveInvis a écrit :
I'm wondering that why semicolon insertion is designed and made it
anti-intuitive?
Automatic Semicolon Insertion (ASI) *was* designed a while ago and can't
be changed whether we find it intuitive or not.
More details at
Le 26/04/2013 00:21, Claus Reinke a écrit :
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted
Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble trib...@e-dean.com wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs
[adding public-script-coord and Anne]
Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
On 26 April 2013 10:54, David Bruant bruan...@gmail.com wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part
Le 26/04/2013 13:24, Andreas Rossberg a écrit :
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows
one to create a
Le 26/04/2013 15:47, Claus Reinke a écrit :
My own argument is not for nested futures themselves, but (1) for
futures to offer the same interface (.of, .then) as other thenables,
which
(2) implies that there is to be no implicit lifting or flattening in
.then.
For promises, I don't expect to
Le 26/04/2013 17:25, Tab Atkins Jr. a écrit :
On Fri, Apr 26, 2013 at 3:19 AM, David Bruant bruan...@gmail.com wrote:
Your abstract example was:
If FutureFuturex can exist, then you'll have to write this
boilerplate code in a lot of places:
f.then(function res(v
Le 26/04/2013 17:58, Mark Miller a écrit :
However, the need for assimilation is history dependent. If there is
another plausible-enough path to adoption and widespread use of
promises that does not require assimilation, I would be very happy.
But I have not found any of the alternatives
Le 26/04/2013 20:39, Domenic Denicola a écrit :
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound
Le 26/04/2013 20:36, Rick Waldron a écrit :
The libraries discussed in this and similar threads have the benefit
of very limited adoption, where breaking changes incur minimal costs.
jQuery doesn't have that luxury ;) [0] and therefore won't break
backward compatibility. I can assure you that
Le 26/04/2013 21:47, Domenic Denicola a écrit :
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be compatible with
Promise/A+ and not jQuery promises? Because more libraries use Promise/A+?
what about market share?
I realize I
Hi,
ES5 remains pretty vague as far as the global object is concerned [1].
Specifically, the [[Class]] is left to the implementation suggesting
that internal [[Get]], [[Set]], etc. are unbounded on what they can do.
For instance, when doing this.Object, an implementation could do
anything
Le 24/04/2013 19:41, Andreas Rossberg a écrit :
On 24 April 2013 19:20, Mark S. Miller erig...@google.com wrote:
On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Q and similar libraries don't actually assume that a FutureFuturex
is a Futurex.
Yes it does. Except of
Le 23/04/2013 17:52, Allen Wirfs-Brock a écrit :
On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
[*] I say probably to hedge my bets. The hard constraint we
absolutely require is already guaranteed by ES5: That the
[[Prototype]] of a non-extensible object cannot be mutated. Given
that, it
Hi,
I've seen a bug report on Firefox [1] and was wondering whether
deterministic property enumeration [2] was still on the table for ES6.
Thanks,
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=865760
[2] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
Le 24/04/2013 11:27, Alex Russell a écrit :
Sorry for the late post. Just wanted to agree with you assessment of
the landscape and options. We should not let theoretical purity poison
the utility of this feature.
Futures as currently spec'ed misbehave in the presence of objects with a
then
Le 23/04/2013 23:47, Rick Waldron a écrit :
On Tue, Apr 23, 2013 at 1:34 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
Based on recent messages on es-discuss, I feel that both
es-discuss and apparently even TC39 meetings with notes have left
Le 20/04/2013 16:03, Brendan Eich a écrit :
David Bruant wrote:
Le 20/04/2013 15:17, Brendan Eich a écrit :
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello
Le 24/04/2013 17:20, Dean Landolt a écrit :
On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller
erig...@google.com mailto:erig...@google.com wrote:
Thoughts?
I was wondering when
Le 23/04/2013 01:31, Tab Atkins Jr. a écrit :
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
What exactly would be the semantic difference between this and just using
'yield'?
The semantic difference is that 'yield' pauses your execution and
gives control to the
Le 22/04/2013 19:32, Dean Landolt a écrit :
I was just saying there will be pressure to include support for
thenables (already in DOMFutures). If you believe otherwise don't let
me dissuade you -- I would absolutely love it if I were proven wrong!
I guess it would take making sure no content
Le 23/04/2013 14:56, Dean Landolt a écrit :
On Tue, Apr 23, 2013 at 4:54 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 22/04/2013 19:32, Dean Landolt a écrit :
I was just saying there will be pressure to include support
for thenables (already
Le 23/04/2013 15:27, Dean Landolt a écrit :
In any case, considering that an object with a 'then'
function is a promise is a recipe for confusion. Promise/A+
folks asked for and are happy about it. The rest of the
webdevs who aren't aware of this subtle
Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
* { [ __proto__ ]: } is not special in any way, and creates a normal property
named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ] property keys
that evaluate to symbols.
I don't know what the agreement is, but
Le 23/04/2013 15:53, Brendan Eich a écrit :
David Bruant wrote:
Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
* { [ __proto__ ]: } is not special in any way, and creates
a normal property named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ]
property keys
Hi,
Based on recent messages on es-discuss, I feel that both es-discuss and
apparently even TC39 meetings with notes have left ambiguity in what
people understood the TC39 agreement was. I believe this ambiguity is
due to this pretty bad communication format called the English language
(For
Le 22/04/2013 14:26, Kevin Smith a écrit :
Thenable futures are uglier than branded futures, but also the only
way to remain compatible with the various libraries that are out there
today, which is something many people value.
What about using a symbol for the `then` protocol?
Le 22/04/2013 15:07, Kevin Smith a écrit :
What about using a symbol for the `then` protocol? Libraries can
be upgraded to use the symbol as an alias for `then`. It set up
a dependency on ES6, of course...
And it doesn't address the compatibility problem people want to
Le 22/04/2013 15:12, Anne van Kesteren a écrit :
On Mon, Apr 22, 2013 at 1:37 PM, David Bruant bruan...@gmail.com wrote:
I personally wonder whether the compatibility with existing libraries is so
important. It should be pretty easy to wrap a native future into a library
future (aren't native
Le 22/04/2013 16:15, Mark S. Miller a écrit :
On Mon, Apr 22, 2013 at 5:37 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 22/04/2013 14:26, Kevin Smith a écrit :
Thenable futures are uglier than branded futures, but also
the only
way
Le 22/04/2013 17:16, Domenic Denicola a écrit :
From: David Bruant [bruan...@gmail.com]
Especially given that it's only for a transitioning period where native (or
polyfilled) have to cohabit with previous library promises?
This is a really bad misconception that you have repeated several
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I'm assuming that that is useful for
security-related applications (Caja et al.). But I'm wondering:
doesn't that go too far? I'm seeing three ways of using
Le 21/04/2013 19:09, Brendan Eich a écrit :
Domenic Denicola wrote:
Doing a quick poll of some IRC rooms, there's some call for
shared-memory multithreading. I know this was a concern of the asm.js
project, or more generally for the JS-as-a-compilation-target
mission. I don't think this is a
Le 20/04/2013 15:17, Brendan Eich a écrit :
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello, destructuring:
let{ proxy, revoke} = Proxy.revocable(target,
Le 18/04/2013 05:07, Tab Atkins Jr. a écrit :
On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
A a rule of thumb, if a library does something that can not be expressed in
the its base language there is a good chance it is extending the virtual
machine of the
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just saying.)
JavaScript does
Le 18/04/2013 13:28, Alex Russell a écrit :
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr.
jackalm...@gmail.com
Le 18/04/2013 14:59, Jorge a écrit :
On 18/04/2013, at 14:40, David Bruant wrote:
I believe the ES spec should provide the primitives of what type of interaction
with the message queue is allowed and what isn't. This set of primitives would
obviously contain all the interactions allowed
Le 18/04/2013 17:35, Kevin Smith a écrit :
Also, can someone point me to a real-world example of delayed
rejection handling?
What do you mean by delayed? If that is: a promise has been rejected
and someone later add a .fail/.catch handler to it, then I've never done
that personally. If you
[es-discuss only fork]
Hi,
I'm forking this as I feel it surfaces an issue which I analyse as being
rooted in the ECMAScript organization. As I describe my opinion below,
please feel free to tell me I'm wrong in my analysis.
I'm sorry this is not a technical discussion, but I nonetheless
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...
Although promises were planned for ES7, they weren't part of any
formal spec. As far as I know, no recent TC39 meetings even mentioned
the concurrency strawman [2].
i don't think
Hi Francisco,
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript.
They try to follow the 1JS rule, that is there is only one language.
Among other things, this makes writing parsers and interpreters easier.
I think this all started at [1] (you don't need to read
Le 16/04/2013 11:54, Andreas Rossberg a écrit :
On 16 April 2013 11:12, David Bruant bruan...@gmail.com wrote:
TC39 (which I'm not part of) agreed to not add more modes to ECMAScript.
They try to follow the 1JS rule, that is there is only one language. Among
other things, this makes writing
Le 13/04/2013 09:31, Andreas Rossberg a écrit :
On 13 April 2013 00:12, Brandon Benvie bben...@mozilla.com wrote:
3.) A new type of primitive along with a new type of wrapper. In this case
we use the String/Number/Boolean precedent where `Symbol()` and `new
Symbol()` produce different kinds of
Le 12/04/2013 14:10, Alex Russell a écrit :
From the DOM side, I don't know that there's enough F2F contact to say
that DOM authors need to be aware of X from the TC39 side will ever
fly without some big checkbox in their lifecycle that says has been
reviewed for idomatic API practice
Le 13/04/2013 03:31, Andrea Giammarchi a écrit :
Do you read internet where every developer calls __proto__ ugly ?
I do read the Internet [1]. I believe Brendan and all TC39 do too.
Let's be super careful when using
every/all/no/none/always/never and other superlatives.
History happened in
Le 11/04/2013 10:39, Tom Van Cutsem a écrit :
2013/4/11 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
In the [[GetRelationship]] algorithm, if r.[[Get]](@geti) is
undefined, then return x.[[Get]](r) but what is this supposed to
do if r is an object?
x[r] would coerce
Le 11/04/2013 14:23, Tom Van Cutsem a écrit :
2013/4/11 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 11/04/2013 10:39, Tom Van Cutsem a écrit :
Yes, but this is also the behavior we have today, right? Nothing
new under the sun. I even wonder whether we can change
Hi,
Feedback based on
http://wiki.ecmascript.org/doku.php?id=strawman:relationships
Curiosity question: What do geti and seti refer to? (the 'i'
specifically)
Is it necessary for r to be able to be a string or a symbol? It looks
superflous, but maybe there is a good reason.
In the
Le 09/04/2013 17:38, Anne van Kesteren a écrit :
On Tue, Apr 9, 2013 at 4:03 PM, David Bruant bruan...@gmail.com wrote:
Following CORS for module imports would make fetching a module require 2
HTTP round-trips (one for the pre-flight IIUC) which is a bummer for
performance.
False.
My mistake
Le 09/04/2013 18:48, Bjoern Hoehrmann a écrit :
* David Bruant wrote:
Opinions differ. Some would say the Same Origin Policy is a legacy
compatibility issue. I'm of that side. It's pretty annoying that a
server-side opt-in is required for sharing. It would be lovely if
sharing on the web
Le 08/04/2013 15:48, Anne van Kesteren a écrit :
On Mon, Apr 8, 2013 at 2:43 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Apr 8, 2013 at 9:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
So modules have not yet landed in ES6, but are planned. I also heard
they will have a pretty
Hi Ohad,
Le 05/04/2013 12:00, Assulin, Ohad a écrit :
Quick question, I would love to submit a feature proposal for
ECMAScript 7 (Function Annotation)
What is the exact process?
People usually just write their proposal in a post to es-discuss or as a
gist [1] in markdown format and post
Thanks for this :-)
The /name/ property is initialized with the best value given static
semantics
= I think all the rules should be explicitly laid out (i think that's
what you did in the subsections after this sentence) to avoid
implementation-specific interpretations of this sentence. Some
Le 03/04/2013 17:54, BelleveInvis a écrit :
I mean, a stack-allocated, immutable, simple, value type, for
high-performance uses.
I think binary data [1] is very close to what you're looking for.
stack-allocated is complicated to ask. It really depends on what the
JS interpreters decides to do
Le 03/04/2013 11:13, Marius Gundersen a écrit :
A core part of the problem here is that the distinction between an
'important' reference - one that must keep an object alive - and an
'incidental' reference, that only need exist as long as it target does...
This is a concept which cannot be
Le 03/04/2013 21:18, Mark S. Miller a écrit :
Do languages which added WeakRefs have a form of revokable
reference too? What difference would it make?
E has both. In practice, my sense is that their use cases are
disjoint, and that both are needed.
Do you have examples of use? May
Le 27/03/2013 00:22, Kevin Gadd a écrit :
OK, it seems like Weak References are now being discussed without the
context of previous discussions of weak references, which is a little
annoying. Non-contrived real-world use cases that require Weak
References (or a primitive with similar
Le 01/04/2013 17:22, Tom Van Cutsem a écrit :
Hi David,
The messages you cite discuss the return value of the oddball
unknownPrivateSymbol trap.
I assumed the comments applied to true/false protocols in general, but
I'm interested if there is disagreement on that point.
For the
Hi,
The current proxy_spec [1], for the Object.preventExtensions built-in,
suggests to read the result of the preventExtensions trap as a boolean
and throw if falsy.
From the developer perspective, this doesn't really add anything since
it's already possible to throw from within the trap (and
Le 31/03/2013 21:17, Jeff Walden a écrit :
On 03/31/2013 11:02 AM, David Bruant wrote:
From the developer perspective, this doesn't really add anything since it's
already possible to throw from within the trap (and that's probably more
explicit and clearer than returning false).
That puts
[answering to different messages at once]
[cc'ing Oliver Hunt as Apple representative and Luke Hoban as Microsoft
representative for questions at the bottom]
Le 27/03/2013 23:47, Brendan Eich a écrit :
You have it backwards. You are advocating a GC design monoculture
(exact rooting only)
My
Le 27/03/2013 00:22, Allen Wirfs-Brock a écrit :
On Mar 26, 2013, at 2:57 PM, David Bruant wrote:
Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit :
On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote:
WeakSet may or may not happen by ES6. But even if it doesn't,
WeakSet is trivially shimmable
201 - 300 of 1196 matches
Mail list logo
