Re: stable sort proposal

Why should you have to opt into to stable sort? Why not the other way around? `Array.prototype.fastestSort` or some such -- or better yet, spec a symbol for it that falls back to `Array.prototype.sort` for implementations that don't expose a faster unstable variety. On Thu, Mar 17, 2016 at 7:35

Re: stable sort proposal

On Tue, Mar 15, 2016 at 12:00 AM, Vic9 wrote: > @Tab Atkins Jr., > > The only question is how much slower/more expensiver stable sorting is > than unstable sorting, and whether that cost is sufficient to outweigh the > usefulness of a stable sort. > My own experiment

Re: stable sort proposal

On Mon, Mar 14, 2016 at 2:16 PM, Tab Atkins Jr. wrote: > On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows > wrote: > > In my honest opinion, there's not much reason to just require the sort > to be > > stable. Some engines have done this in the past,

Re: Any reason why __proto__ is not a well known symbol?

On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. wrote: > On Mon, Feb 15, 2016 at 9:14 PM, Coroutines wrote: > > On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. > wrote: > >> It was specified before symbols existed, and all

Re: Re: Just try

On Fri, Oct 30, 2015 at 2:17 PM, Alican Çubukçuoğlu < alicancubukcuo...@gmail.com> wrote: > The recommended way of checking for file existence in Node.js is calling > `fs.stat()` on the file. If no error was passed to the callback, it exists. > If "ENOENT" was passed, it doesn't. > > If you

Re: Exporting Symbols

The symbol registry is a great way to map universal (not just global, but fully cross-realm) names (strings) to unique, distinct concepts (symbols). But as a flat string namespace has all the same kinds of issues symbols were introduced to solve. IIUC throwing `Math.random` strings into the symbol

Re: Exporting Symbols

[snip] > So if you export an opaque identity that you created yourself, and don't > expose some mechanism for downstream consumers to know what it means, > you're handing a bag of meaningless tokens which are, by definition, > completely useless to them. > I should add: if you only intend to

Re: Exporting Symbols

On Fri, Oct 16, 2015 at 3:46 PM, Rick Waldron <waldron.r...@gmail.com> wrote: > > > On Fri, Oct 16, 2015 at 2:47 PM Dean Landolt <d...@deanlandolt.com> wrote: > >> The symbol registry is a great way to map universal (not just global, but >> fully cross-realm)

Re: Please help with writing spec for async JSON APIs

On Tue, Aug 4, 2015 at 9:53 AM, Mark Miller erig...@gmail.com wrote: +1 for line delimited JSON. It would be good to switch all users of json-seq over to it and to deprecate json-seq. Perhaps an RFC would help. On Mon, Aug 3, 2015 at 11:53 PM, Bruno Jouhier bjouh...@gmail.com wrote: RFC

Re: await on synchronous functions

On Sun, Jul 26, 2015 at 8:07 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: Out of curiosity, can you give an example of the Not Good parts? ISTM the await prefix is more of an explicit cast than an implicit conversation, and other than the very small timing gap in how throws are handled

Re: await on synchronous functions

On Thu, Jul 23, 2015 at 9:06 AM, Andreas Rossberg rossb...@google.com wrote: On 17 July 2015 at 23:39, Mark S. Miller erig...@google.com wrote: On Fri, Jul 17, 2015 at 10:41 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: If I might, if there's one thing that has never

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Meaning putting a Promise in a chain of promises is a point of no return so I've never seen/heard/imagined a case where you have a promise and suddenly you refactor that to be synchronous. This is a great

Re: How to tell function and generator function apart?

One use case is for coroutine runners which accept either generators or generator functions: https://github.com/deanlandolt/copromise/blob/master/copromise.js#L34-L36 Is there a better way to accomplish this? On Tue, Mar 3, 2015 at 12:12 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: Why

Re: How to tell function and generator function apart?

On Tue, Mar 3, 2015 at 10:00 PM, Domenic Denicola d...@domenic.me wrote: That's not really the issue at hand, though. Your runner won't work with functions that manually return generator instances, due to its type-testing. Even if those functions return generator instances express a perfectly

Re: How to tell function and generator function apart?

On Tue, Mar 3, 2015 at 5:26 PM, Domenic Denicola d...@domenic.me wrote: As discussed previously such overloading is pretty bad. If someone creates a generator-returning function manually, instead of using a generator function to do so, they will start getting unexpected results from your

Re: The result of Generator.prototype.return

On Wed, Feb 25, 2015 at 2:39 PM, Bergi a.d.be...@web.de wrote: Axel Rauschmayer schrieb: OK. I see the use case for `throw()` (e.g. to convert a promise rejection into an exception when using generators for async). The only use case for `return()` is closing an iterator, then(?) If you

Re: (x) = {foo: bar}

an (accidentally) unwrapped object literal to parse. If it's not a well-labeled statement, it's surely a mistake. Marius Gundersen On 6 Jan 2015 19:42, Brendan Eich bren...@mozilla.org wrote: Sorry, sent too soon. Dean Landolt wrote: If it's too late to properly vet a change which narrowly excludes

Re: (x) = {foo: bar}

On Mon, Jan 5, 2015 at 6:06 PM, Brendan Eich bren...@mozilla.org wrote: Jasper St. Pierre wrote: Unless x = {foo: bar} and x = {} both parse as object literals, I'm against your proposal. Either un-paren'd braces are consistently a block, or they're consistently an object

Re: Promise-returning delay function

On Tue, Oct 28, 2014 at 10:41 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: The moment you pass a promise you have no control on who's adding what as callback or errorback which means you have no control over a .reject() or over a .success() .cancel() would eventually keep both

Re: My ECMAScript 7 wishlist

On Fri, Sep 26, 2014 at 10:29 AM, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: I don't understand how you inferred from Andrea's post that this wish-fulfillment __noSuchProperty__ magic property does not have to handle superclass delegation.. I did not infer that from

Re: Does async/await solve a real problem?

Yes, async/await solves one problem in particular that generators alone cannot—the ability to `await` some asynchronous value from within a true generator (one yielding actual values, not a coroutine yielding promises or thunks into a trampoline). These coro trampolines are a clever hack, but the

Re: restrictions on let declarations

On Thu, Jan 30, 2014 at 10:59 AM, John Barton johnjbar...@google.comwrote: On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote: John Lenz wrote: Generally, I've always thought of: if (x) ... as equivalent to if (x) { ... } let and const (and class) are

Re: Operator overloading for non-value objects

Value Objects. See the recent thread re: value objects on es-discuss. Slides from the presentation Brendan linked to ( http://www.slideshare.net/BrendanEich/js-resp) confirm that == will still be overloadable and he says he'll be working on writing it all up this month. On Mon, Jan 13, 2014 at

Re: Operator overloading for non-value objects

On Mon, Jan 13, 2014 at 8:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 13, 2014 at 1:13 PM, Dean Landolt d...@deanlandolt.com wrote: Value Objects. See the recent thread re: value objects on es-discuss. Slides from the presentation Brendan linked to (http

Re: Why thenables?

True, though if you're using modules like that you won't need thenable assimilation anyway -- you can count on your code having native promises. If I understood Alex Russell correctly the core problem is cross-realm promise polyfillability. It seems to me we could solve this problem by just

Re: Why thenables?

On Fri, Dec 20, 2013 at 12:38 PM, Kevin Smith zenpars...@gmail.com wrote: Okay, so how will end users or jQuery authors upgrade their promises to become ES6-compliant? I don't know enough about jQuery's internals to write convincing code, but the basic idea is that you feature detect for

Re: const VS features detection

On Fri, Dec 20, 2013 at 2:14 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: This is not helping ... yeah, apples-to-orange, as you wish .. now to imagine you have a flexible understanding of the issue and the example I was proposing so that: if (stuff) { const WHATEVER = 1; }

Re: any toMethod() use case ?

On Tue, Dec 3, 2013 at 4:24 PM, Brian Di Palma off...@gmail.com wrote: This is sort of OT but not too much. I have a concern about how mixins will be implemented in ES. It concerns clashing property identifiers in mixins and the classes taking their behavior. By way of a simple example an

Re: Novel operator syntax

The PEP Tristan posted offers a pretty compelling case for distinguishing elementwise operators from objectwise ones (although not for this dot syntax per se, they went with a ~-prefix): http://www.python.org/dev/peps/pep-0225/ On Tue, Oct 29, 2013 at 2:25 PM, Brendan Eich bren...@mozilla.com

Re: Protocol library as alternative to refinements (Russell Leggett)

First off, this whole concept is brilliant. Thanks for sharing, Russell. Just a few comments inline... On Tue, Oct 22, 2013 at 2:13 AM, Russell Leggett russell.legg...@gmail.comwrote: I can see most of your examples involve the interaction between the protocol method and a method supplied

Re: Protocol library as alternative to refinements (Russell Leggett)

problematic to me (I don't see an obvious behavioral way though (how do I say Array like?), and having a default implementation kind of addresses that). On Tue, Oct 22, 2013 at 5:35 PM, Dean Landolt d...@deanlandolt.com wrote: I think the idea of overriding at the instance level

Re: Protocol library as alternative to refinements (Russell Leggett)

On Tue, Oct 22, 2013 at 12:19 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: Dean Landolt d...@deanlandolt.com wrote: Say you have an object for which you want to implement the Cowboy and Canvas protocols (to borrow /be's favorite example). Both implement a draw method, but when

Re: Protocol library as alternative to refinements (Russell Leggett)

On Tue, Oct 22, 2013 at 12:44 PM, Russell Leggett russell.legg...@gmail.com wrote: Say you have an object for which you want to implement the Cowboy and Canvas protocols (to borrow /be's favorite example). Both implement a draw method, but when you try to import from both protocols you'll

Re: Protocol library as alternative to refinements (Russell Leggett)

On Tue, Oct 22, 2013 at 4:07 PM, Russell Leggett russell.legg...@gmail.comwrote: On Tue, Oct 22, 2013 at 2:34 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett russell.legg...@gmail.com wrote: Revised algorithm: 1. If receiver has

Re: Readdition of __proto__

On Mon, Oct 14, 2013 at 8:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Oct 14, 2013, at 4:21 PM, Andrea Giammarchi wrote: my last memories on the topic are these: ```javascript var obj = JSON.parse('{__proto__:[]}'); obj instanceof Array; // false obj.__proto__

Re: Readdition of __proto__

On Tue, Oct 15, 2013 at 5:50 PM, Brendan Eich bren...@mozilla.com wrote: Benjamin (Inglor) Gruenbaum wrote: Not resolving this like o3 (or o6 really) sounds very strange. I think: let attr = __proto__; let o7 = new Object; o7[attr] = p; // o7 inherits from p Is the correct behavior here

Re: Comments on Sept Meeting Notes

On Wed, Sep 25, 2013 at 12:04 AM, Kevin Smith zenpars...@gmail.com wrote: This seems like a non-sequitur. Symbols aren't meant to help with the object as map use-case, and even if you tried to, they work terribly for it. They're meant for the add an actual property/method without collision

Re: Letting RegExp method return something iterable?

On Thu, Aug 29, 2013 at 4:13 AM, Brendan Eich bren...@mozilla.com wrote: Axel Rauschmayer wrote: * /g flag must be set * lastIndex must be 0 * can’t inline the regex, because it is needed as a pseudo-iterator (more of an anti-pattern, anyway, but still) * side effects via lastIndex may be

Re: Why not private symbols?

On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.com wrote: Aside from this confinement issue, all other the advantages that unique symbols have over unique-ish strings seem minor to me. The biggest is default non-enumerability, when we're getting away (admittedly slowly) from

Re: Agreeing on user-defined unique symbols?

We have exactly the same problem with inter-realm instanceof. The module system is the obvious solution for system-defined unique symbols. I've been assuming it could be hacked (one way or another) into giving us a registry where we could map string keys to symbols across realms. I get that this

Re: Why not private symbols?

On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller erig...@google.com wrote: On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt d...@deanlandolt.comwrote: On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.comwrote: Aside from this confinement issue, all other the advantages

Re: Agreeing on user-defined unique symbols?

On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller erig...@gmail.com wrote: On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: One way could be to have a shared module with the symbol that both w1.1 and w1.2 uses. // w-symbols.js export let foo = Symbol(); //

Re: Agreeing on user-defined unique symbols?

On Wed, Jul 31, 2013 at 1:50 PM, Kevin Smith zenpars...@gmail.com wrote: unique string (uuid or otherwise) suffer same problem if generated in 2 different realm unaware of each other. I meant hard-coding such a well-known unique string into both versions of the library. That solves the

Re: Agreeing on user-defined unique symbols?

Why a third namespace when there's the built-in modules that functions nicely as our registry? On Wed, Jul 31, 2013 at 1:57 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich bren...@mozilla.com wrote: Domenic Denicola wrote:

Re: Unique Public Symbols as Strings

' for two reasons, I think: 1, lack of symbol spec of implementation as prerequisite; 2, belief that a public name was better. Jason argued that case here, but I don't think he prevailed (Dean Landolt disagreed). FWIW Jason convinced me in the end -- I was subtly misinterpreting the spec. I

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 12:31 PM, Andreas Rossberg rossb...@google.comwrote: On 19 July 2013 18:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote: You have to be able to support Proxy exotic objects so, I don't see why you won't use that exact mechanism for Symbol objects. Because they are

Re: How primitive are Symbols? Bignums? etc

On Fri, Jul 19, 2013 at 2:48 PM, Andreas Rossberg rossb...@google.comwrote: On 19 July 2013 19:41, Dean Landolt d...@deanlandolt.com wrote: I'm curious how symbols differ semantically from null-prototype, empty, frozen objects? They differ in that the extra cruft that's needed to represent

Re: Frozen Date objects?

On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote: Norbert Lindenberg wrote: On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote: This is unfortunate. It does

Re: How primitive are Symbols? Bignums? etc

On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 ( https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in

Re: Why does Array.from accept non-iterable arraylikes?

On Fri, Jun 28, 2013 at 9:59 AM, Jason Orendorff jason.orendo...@gmail.comwrote: On Thu, Jun 27, 2013 at 1:04 PM, Dean Landolt d...@deanlandolt.com wrote: On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff jason.orendo...@gmail.com wrote: If you mean a library function that expects either

Re: Why does Array.from accept non-iterable arraylikes?

On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Jun 26, 2013 at 7:54 PM, Dean Landolt d...@deanlandolt.com wrote: On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff jason.orendo...@gmail.com wrote: What if iterator is present but not a function

Re: Why does Array.from accept non-iterable arraylikes?

On Wed, Jun 26, 2013 at 6:23 AM, Claude Pache claude.pa...@gmail.comwrote: Iterables are useful not only in for/of loops but also in otherwise polyfillable constructs; for example, in the Set constructor: // Let `a` be a Set object b = new Set(a) // copy the elements of `a` into a

Re: Why does Array.from accept non-iterable arraylikes?

On Wed, Jun 26, 2013 at 9:38 AM, Jason Orendorff jason.orendo...@gmail.comwrote: On Tue, Jun 25, 2013 at 9:36 PM, Brandon Benvie bben...@mozilla.com wrote: I think that the iteration protocol falls under the type of thing that is better exposed through this layer of faux-stratification

Re: Why does Array.from accept non-iterable arraylikes?

On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Jun 26, 2013 at 10:20 AM, Dean Landolt d...@deanlandolt.com wrote: I assume the primary reason to hang the iterator reference directly off an object is so that it can be prototypally overloaded

Re: Why does Array.from accept non-iterable arraylikes?

On Wed, Jun 26, 2013 at 1:31 PM, Brendan Eich bren...@mozilla.com wrote: Dean Landolt wrote: sometimes it can fail in a way where you may want to proceed up the prototype chain (or do something else). This is where I believe there are interop landmines buried. How is this different from

Re: Why does Array.from accept non-iterable arraylikes?

On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Wed, Jun 26, 2013 at 12:15 PM, Dean Landolt d...@deanlandolt.com wrote: On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff jason.orendo...@gmail.com wrote: If we make the name just plain iterator, there's

Re: Why does Array.from accept non-iterable arraylikes?

On Tue, Jun 25, 2013 at 1:33 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jun 25, 2013, at 10:19 AM, Anne van Kesteren wrote: On Tue, Jun 25, 2013 at 4:58 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Jun 25, 2013 at 10:42 AM, Sam Tobin-Hochstadt

Re: Why does Array.from accept non-iterable arraylikes?

On Tue, Jun 25, 2013 at 2:16 PM, Brandon Benvie bben...@mozilla.com wrote: On 6/25/2013 10:33 AM, Allen Wirfs-Brock wrote: We could make an exception for iterator, but why? That just introduces an inconsistency in the design. I think the motivation was to make it easier to polyfill, but I

Re: Object.values and/or Object.forEach ?

The for/of iterators solve this nicely. This is definitely something that comes up a lot though, and this seems like a very handy cowpath to pave. If it were spec'd I'd suggest the naming and argument values should align with the for/of variants. On Fri, Jun 7, 2013 at 12:57 PM, Andrea

Re: Object.values and/or Object.forEach ?

idiom too (without the more heavyweight preprocessing necessary for polyfilling import syntax). On Fri, Jun 7, 2013 at 1:25 PM, Brandon Benvie bben...@mozilla.com wrote: On 6/7/2013 10:18 AM, Dean Landolt wrote: The for/of iterators solve this nicely. This is definitely something that comes up

Re: The Paradox of Partial Parametricity

On Tue, May 28, 2013 at 12:24 PM, Russell Leggett russell.legg...@gmail.com wrote: On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, May 27, 2013 at 9:53 AM, Russell Leggett russell.legg...@gmail.com wrote: On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr.

Re: B.3.1 The __proto__ pseudo property

Call me crazy but I can picture a world where you have to explicitly shim in __proto__ (using Object.setPrototypeOf) if you really need it. Not anytime soon, sure, but maybe one day. Maybe... On Wed, May 8, 2013 at 5:05 PM, Brendan Eich bren...@mozilla.com wrote: Having Object.setPrototypeOf

Re: __defineGetter__ returns

On Tue, May 7, 2013 at 10:13 AM, Rick Waldron waldron.r...@gmail.comwrote: On May 7, 2013 3:49 AM, David Bruant bruan...@gmail.com wrote: Hi, The latest rumors [1] suggest that __defineGetter__ will be in IE11. Of course to benefit platform compatibility, but that doesn't mean ES6 (or

Re: __defineGetter__ returns

On Tue, May 7, 2013 at 11:59 AM, Rick Waldron waldron.r...@gmail.comwrote: On Tue, May 7, 2013 at 10:21 AM, Dean Landolt d...@deanlandolt.comwrote: On Tue, May 7, 2013 at 10:13 AM, Rick Waldron waldron.r...@gmail.comwrote: On May 7, 2013 3:49 AM, David Bruant bruan...@gmail.com wrote

Re: __defineGetter__ returns

...@mozilla.com wrote: On 5/7/2013 9:09 AM, Dean Landolt wrote: TC39 already specifies the other dunders in Annex B. Not currently. With IE11 adding them, though, it would make sense to add them to Annex B. __**_ es-discuss mailing list es-discuss

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 11:18 AM, Andreas Rossberg rossb...@google.comwrote: On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote: The fundamental controversy, as Juan just noted, is how to precisely identify a promise in order to do either of these two things. This problem

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 9:36 AM, David Bruant bruan...@gmail.com wrote: 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

Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola dome...@domenicdenicola.com wrote: 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+?

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren ann...@annevk.nlwrote: On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller erig...@google.com wrote: Thoughts? I was wondering when operator overloading is planned. It would be great to be able to do things like new URL(http://example.org;)

Re: Futures (was: Request for JSON-LD API review)

On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Andreas Rossberg [rossb...@google.com] Mark, could you summarize the rationale for this, or provide a more specific link to

Re: Futures

On Tue, Apr 23, 2013 at 4:54 AM, David Bruant 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 in DOMFutures). If you believe otherwise don't let me dissuade you -- I would absolutely

Re: Futures

On Tue, Apr 23, 2013 at 9:12 AM, David Bruant bruan...@gmail.com wrote: Le 23/04/2013 14:56, Dean Landolt a écrit : On Tue, Apr 23, 2013 at 4:54 AM, David Bruant bruan...@gmail.com wrote: Le 22/04/2013 19:32, Dean Landolt a écrit : I was just saying there will be pressure to include

Re: Futures

On Tue, Apr 23, 2013 at 9:37 AM, David Bruant bruan...@gmail.com wrote: 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

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Sun, Apr 21, 2013 at 9:29 PM, Mark S. Miller erig...@google.com wrote: Agreed that Object.freeze does not give you what you need. RiverTrail already needs a kind of collection that is transitively immutable by construction. They need this for safe data parallelism. But the reason they are

Re: Futures

On Mon, Apr 22, 2013 at 10:15 AM, Mark S. Miller erig...@google.com wrote: On Mon, Apr 22, 2013 at 5:37 AM, David Bruant 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 to remain compatible with

Re: Futures

On Mon, Apr 22, 2013 at 11:16 AM, Domenic Denicola dome...@domenicdenicola.com wrote: 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

Re: Futures

is the promise is in 'this') These 2 lines (+wrapNativeFuture) sound pretty practical to me for the transition period. It sounds like a reasonable compromise for libraries to work with built-in promises without imposing a burden on top of these. Dean Landolt wrote: FWIW I disagree with him

Re: Futures

On Mon, Apr 22, 2013 at 12:47 PM, Kevin Smith zenpars...@gmail.com wrote: FWIW I disagree with him -- I strongly suspect that by the time this were to all go down and a stable polyfill existed there'd already be too much then-demanding code in the wild. There probably already is. And at

Re: Futures

On Mon, Apr 22, 2013 at 1:53 PM, Kevin Smith zenpars...@gmail.com wrote: I would love to see this, but best I can tell it can't be a straitforward polyfill. The necessary infrastructure has to settle, and what are Promises/A+ implementers supposed to do in the meantime? Presumably the

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote: I'll add this as a second option to the strawman. 2013/4/9 Sorin Mocanu sorinmoc...@google.com Thank you Nebojša. How about if the

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

need a custom cons anyway. On Mon, Apr 15, 2013 at 9:33 AM, Claude Pache claude.pa...@gmail.comwrote: Le 15 avr. 2013 à 14:43, Dean Landolt d...@deanlandolt.com a écrit : On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Apr 9, 2013

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

On Mon, Apr 15, 2013 at 10:01 AM, Dean Landolt d...@deanlandolt.com wrote: Perhaps I wasn't clear: I was proposing the timezone property as purely informative for the locale methods. The Date constructor used to revive the IDB value will dictate the date's timezone, so no, the cloned date

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Apr 15, 2013, at 5:43 , Dean Landolt wrote: On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: I'm afraid this would be quite confusing. Many

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

On Mon, Apr 15, 2013 at 2:13 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Apr 15, 2013, at 9:23 , Dean Landolt wrote: On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Apr 15, 2013, at 5:43 , Dean Landolt wrote

Re: a future caller alternative ?

On Mon, Mar 11, 2013 at 5:51 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the outer `with` statement ... you see my point? we are dropping powerful features in order to make JavaScript the toy we all think is since ever, isn't it fear driven features, SES I've never

Re: a future caller alternative ?

On Mon, Mar 11, 2013 at 7:57 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt d...@deanlandolt.comwrote: it's not the same thing as apply, bind, or call -- in each of the latter forms you're explicitly handing out the `this` reference

Re: Internationalization: Support for IANA time zones

On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ m...@macchiato.com wrote: It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. *Maybe there's just no value in trying to define something

Re: Check out Dart's iterators

Has the iteration protocol been given a close look since unique symbols hit the scene? I know the iterator key was changed to a symbol (which makes great sense) but ISTM symbols offer up some design flexibility that, as far as I know, just isn't possible in any of the other languages mentioned WRT

Re: Ducks, Rabbits, and Privacy

On Tue, Jan 22, 2013 at 11:13 AM, Brandon Benvie bran...@brandonbenvie.comwrote: I also agree with everything that Nathan said. To clarify, there's Symbols and then there's private Symbols. I don't think anyone in TC39 is suggesting the removal of Symbols in general. Private Symbols have a

Re: Ducks, Rabbits, and Privacy

On Tue, Jan 22, 2013 at 4:03 PM, Kevin Smith khs4...@gmail.com wrote: +1 to this and everything else Nathan has said. Watching all this intense back and forth, there are a lot of good points, some of which almost convince me that weak maps are sufficient and private symbols are unnecessary.

Re: (Map|Set|WeakMap)#set() returns `this` ?

On Thu, Dec 6, 2012 at 2:41 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron waldron.r...@gmail.comwrote: values() returns an iterable of the values in the array. Array, Map and Set will receive all three: keys(), values(), entries(). Feel

Re: Symbols, Protocols, Frames, and Versioning

On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote: On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote: Sounds good. As an aside, does the symbol in this case provide any

Re: Symbols, Protocols, Frames, and Versioning

On Fri, Oct 5, 2012 at 9:51 AM, Dean Landolt d...@deanlandolt.com wrote: On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote: On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote

Re: Symbols, Protocols, Frames, and Versioning

On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.com wrote: Tab Atkins Jr. wrote: It might be useful to expose this functionality with a more obvious name, to underscore that you lose the secrecy/unforgability. Symbol.public()? We are mooting public as the keyword for

Re: Symbols, Protocols, Frames, and Versioning

On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote: Dean Landolt wrote: On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.commailto: bren...@mozilla.com wrote: Tab Atkins Jr. wrote: It might be useful to expose this functionality with a more

Re: Symbols, Protocols, Frames, and Versioning

On Thu, Oct 4, 2012 at 3:24 PM, Brendan Eich bren...@mozilla.com wrote: Dean Landolt wrote: On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.commailto: bren...@mozilla.com wrote: Urgh, namespace is misleading, it suggests Common Lisp's symbol packages, the AS3/ES4

Re: Suggestions for Set

On Wed, Oct 3, 2012 at 3:47 AM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Wed, Oct 3, 2012 at 10:24 AM, Andreas Rossberg rossb...@google.comwrote: On 3 October 2012 05:38, Brendan Eich bren...@mozilla.com wrote: Which is more important, iterating over holes (preserved if

Re: Sets plus JSON

On Wed, Oct 3, 2012 at 2:19 PM, Rick Waldron waldron.r...@gmail.com wrote: On Wed, Oct 3, 2012 at 2:04 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Oct 3, 2012 at 1:43 PM, Brandon Benvie bran...@brandonbenvie.com wrote: Another options for Maps is to represent them as an array

Re: Symbols, Protocols, Frames, and Versioning

On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich bren...@mozilla.org wrote: Domenic Denicola wrote: Would it suffice to allow cross-frame sharing of symbols via postMessage and its structured clone algorithm? They're immutable, right? They are immutable but you'd still have to pass your

Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes)

On Mon, Oct 1, 2012 at 12:00 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Oct 1, 2012 at 5:26 AM, Andreas Rossberg rossb...@google.comwrote: On 30 September 2012 00:08, Brendan Eich bren...@mozilla.org wrote: I think this is too philosophical a discussion to result in a strong

  1   2   3   >