Re: Will not make it to this week's meeting

Hope you get well quickly. On Tue, Sep 22, 2015 at 2:55 AM, Waldemar Horwat wrote: > I had a medical emergency (broken bones) soon after arriving in Portland > and am flying back to the bay area today for surgery and treatment. I will > unfortunately have to miss this

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

I do not share Mark's view. Contra his sentiment, I was using the small version of JS for many years and noted that most non-trivial uses required finding or building a library. That choice of library (which exist to fill in platform and language deficiencies) leads to a a split in common use

Re: about lightweight traits

Traits as class make perfect sense when you consider that classes are functions and so are traits. On Thu, Feb 12, 2015 at 10:27 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: this thousand times ... Traits as class makes no sense to me indeed and Mark example shows plain objects

Re: Removal of WeakMap/WeakSet clear

I support Katelyn's suggestion to make clear() neuterable on an instance, perhaps with per-object configuration. It leaves the API intact while allowing those with security concerns to address them. On 4 Dec 2014 20:01, Katelyn Gadd k...@luminance.org wrote: JSIL has a shim that emulates the 2D

Re: ... A community is writing the spec...

Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like

Re: .entries() vs. the web

Right. Would love to know the size/traffic of the number of sites affected. On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron waldron.r...@gmail.com wrote: On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich bren...@mozilla.org wrote: Would .items fare better, I wonder. Or outreach to sites

Re: .entries() vs. the web

`Array` and ` Object` could be passed as parameter but yeah, objects with properties named as `list`, `items`, or `entries` are quite common but I personally prefer a future proof approach/small refactoring than a stopper for new specs. my 2 cents On Tue, Jun 17, 2014 at 11:18 AM, Alex

Re: New ES6 draft (Rev23) now available

4.3.25 doesn't seem to have a title name in the HTML export. I'm assuming some sort of Word black magic is to blame? On Thu, Apr 10, 2014 at 7:13 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Sun, Apr 6, 2014 at 1:41 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The April 5,

Re: async decision making (was Re: Promise.cast and Promise.resolve)

On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote: Edward O'Connor wrote: Perhaps TC39 should consider adopting a similar policy. Policy, schmolicy :-P. (Presumably clocks with deadlines are required; consensus could break afterwards, in spite of the formal rules.)

Re: Why thenables?

On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg rossb...@google.comwrote: On 19 December 2013 23:29, Alex Russell slightly...@google.com wrote: Right, but number of objects you have to guard with anti-branding is much, much larger. That argues against thenables pretty strongly, but again

Re: Why thenables?

On Thu, Dec 19, 2013 at 9:24 AM, Mark S. Miller erig...@google.com wrote: I think this anti-branding idea is worth considering, but using a symbol or weakmap for the anti-branding rather than a magic double-underbar property name. Unlike prior positive thenable branding proposals, this one

Re: Why thenables?

Right, but number of objects you have to guard with anti-branding is much, much larger. That argues against thenables pretty strongly, but again, I don't think we need to change anything for ES6. We can repair this in ES7 if it's a problem in practice. On Thu, Dec 19, 2013 at 2:21 PM, Gorgi

Re: Re: Why thenables?

On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: I understand that adding branding to promises is impossible at this point, as it would break backward compatibility with all existing implementations. That wasn't the overriding consdieration. I don't care if we don't

Re: Re: Why thenables?

On 18 Dec 2013 18:20, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Alex can I ask you if there's any specific deadline you are talking about? Promises aren't important. They are a tool. And the design space is *clearly* overconstrained. Anyone paying attention can see that. We should

Re: Why thenables?

On 18 Dec 2013 20:27, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: On 12/19/2013 02:56 AM, Alex Russell wrote: On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: I understand that adding branding to promises is impossible at this point, as it would break backward

Re: Reserving await within Arrow Functions

If you can't indicate that the arrow itself is async somehow (either by prefixing it with deferred or async or using a variant of the arrow itself, e.g. ~=), then you get into the issue Brendan describes when you allow await inside the body. On Thu, Dec 12, 2013 at 10:07 AM, Kevin Smith

Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker hal...@gmail.comwrote: On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee ti...@w3.org wrote: JSON is interesting in being a subset of ECMAscript. That is a big dependency -- will it be preserved? However as it is unwise to feed JSON into

Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

Will you also be citing ECMA-404 normatively to avoid this sort of divergence in the future? On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray tb...@textuality.com wrote: To do this, I think the draft requires these changes: - Remove the trailing section of section 1.2, starting with “ECMAscript

Re: Are Promises and Microtasks introduced into ES6?

On 3 Oct 2013 08:23, Yusuke SUZUKI yusukesuz...@chromium.org wrote: Hi, I'm very interested in implementing Promises and integrating it to ECMAScript engine (e.g. V8, SpiderMonkey, JSC) Last night, I saw the meeting notes of Sep TC39 meetings carefully and I was very surprised that it is

Re: Safe, Closure-free, Serializable functions

It's unclear what your threat model is. What do you want to defend, from who or what, and for how long? On 26 Sep 2013 00:40, Aymeric Vitte vitteayme...@gmail.com wrote: This is similar to the Native thread as Andrea mentioned. Then when SES is coming? It seems urgent to boost it, I have

Re: Safe, Closure-free, Serializable functions

the result does secure, as well as [2] Regards Aymeric Le 26/09/2013 18:14, Alex Russell a écrit : It's unclear what your threat model is. What do you want to defend, from who or what, and for how long? On 26 Sep 2013 00:40, Aymeric Vitte vitteayme...@gmail.com wrote: This is similar

Re: Killing `Promise.fulfill`

So what? This isn't bad. It's just what happens in implementations where you don't have timeouts enforced by the system. C'est la vie. On Monday, August 19, 2013, Domenic Denicola wrote: In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html(plus following errata) I created

Re: Future cancellation

Mail *From:* Alex Russell *Sent:* Tuesday, April 30, 2013 2:54 AM *To:* Ron Buckton *Cc:* es-discuss, public-script-co...@w3.org javascript:_e({}, 'cvml', 'public-script-co...@w3.org');, Tab Atkins Jr. These are horribly confused -- and likely foot-gun -- designs. First, synchronous

Re: Future cancellation

On Wednesday, May 1, 2013, Jonas Sicking wrote: On Mon, Apr 29, 2013 at 6:57 PM, Ron Buckton rbuck...@chronicles.orgjavascript:; wrote: I’ve created separate gists for three different ways that I am currently investigating as a means to support the cancellation of a Future. These can

Re: Future cancellation

These are horribly confused -- and likely foot-gun -- designs. First, synchronous resolution needs some justification. I don't understand why you've added it in the first design. The question of does the Resolver know it is resolved? is entirely independent of the visibility of that resolution to

Re: Futures

On Friday, April 26, 2013, Tab Atkins Jr. wrote: On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell slightly...@google.comjavascript:; wrote: On Apr 26, 2013 8:33 PM, Tab Atkins Jr. jackalm...@gmail.comjavascript:; wrote: On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Yes, you do. On Apr 26, 2013 2:54 PM, Kevin Smith zenpars...@gmail.com wrote: 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

Re: Futures

On Apr 26, 2013 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com wrote: Actually, I may have gotten it terribly wrong (apologies). In my prototype implementation, the following:

Re: Futures

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

Re: Futures

On Apr 22, 2013 5:29 PM, Mark S. Miller erig...@google.com wrote: On Mon, Apr 22, 2013 at 8: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

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

Hi Ron, Comments inline. On Wed, Apr 17, 2013 at 7:35 PM, Ron Buckton ron.buck...@microsoft.comwrote: As someone who has been interested in Promises/Futures in JavaScript for a number of years, I'd like to throw in my $0.02 regarding a proposed API for Promises/Futures for thoughts:

Re: More flexibility in the ECMAScript part?

On Thu, Apr 18, 2013 at 8:48 AM, David Bruant 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 wrote: Note that Futures are entirely expressible in today's JS semantics. (Not to say that it

Re: Futures

Mark: It's also unfortunate and incorrect to say the w3c forked this. This plan was fleshed out on public-script-coord and you've been part of the evolution of the proposal ever since. I don't understand what, if anything, you're objecting to. On Wed, Apr 17, 2013 at 5:49 PM, Robin Berjon

Re: A Precedent

Hey Andrea, Response inline. On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: a principle or rule established in a previous case: http://en.wikipedia.org/wiki/Precedent I should not be here and I will not answer, just my last attempt trying to make a

Re: Coordination (was: ES6 Modules)

On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.org wrote: On 09/04/2013 16:51 , Brendan Eich wrote: First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of

Re: Coordination (was: ES6 Modules)

On Friday, April 12, 2013, Rick Waldron wrote: On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell slightly...@google.comjavascript:_e({}, 'cvml', 'slightly...@google.com'); wrote: On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.orgjavascript:_e({}, 'cvml', 'ro...@w3.org'); wrote

Re: Machine readable specifications

I expect that what you'll hear from implementers is that parsing isn't the hard bit of a modern JS engine -- it's certainly not the thorniest part of Traceur, and it doesn't do _most_ of the work a JIT-ing engine would. If you would like to concretely improve the situation, you might ask Allen

Re: Are frozen Objects faster ?

On Thursday, February 14, 2013, Andreas Rossberg wrote: On 14 February 2013 19:26, Herby Vojčík he...@mailbox.sk javascript:; wrote: I meant de facto. People wanting to remove property bar from foo do not write `delete foo.bar` anymore; they (at least some significant subset) have

RE: Check out Dart's iterators

FWIW, there continue to be strong misgivings about the pythonesqe design we have now, but Mozilla insists on the back of their shipping implementation. Many feel that exceptions for control-flow are a missdesign, myself included, but at this point the ship us nearly past the lighthouse on its way

Re: direct_proxies problem

On Tuesday, January 8, 2013, Tab Atkins Jr. wrote: On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi andrea.giammar...@gmail.com javascript:; wrote: So, I am playing with FF 18 and I have this behavior: var a = new Proxy([], {}); console.log(a instanceof Array); // true

Re: URLs / subclassing JavaScript

hey Anne, Sam! Comments inline: On Monday, December 17, 2012, Sam Tobin-Hochstadt wrote: On Mon, Dec 17, 2012 at 9:19 AM, Anne van Kesteren ann...@annevk.nljavascript:; wrote: If down the road we want to allow for the theoretical possibility of having all platform APIs implemented in

Re: A DOM use case that can't be emulated with direct proxies

+1. What Andreas said. On Friday, December 14, 2012, Andreas Rossberg wrote: On 13 December 2012 19:21, Mark S. Miller erig...@google.comjavascript:; wrote: On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.comjavascript:; wrote: As you say, to remain viable, it must be

Re: A DOM use case that can't be emulated with direct proxies

Window interceptors (as we call them in the browser world) are simply nuts. We simply shouldn't be terribly interested in re-creating this wart. On Wednesday, December 12, 2012, David Bruant wrote: Le 12/12/2012 20:29, Kevin Reid a écrit : On Wed, Dec 12, 2012 at 11:19 AM, David Bruant

Re: A DOM use case that can't be emulated with direct proxies

Yep. On Wednesday, December 12, 2012, David Bruant wrote: Le 12/12/2012 20:44, Alex Russell a écrit : Window interceptors (as we call them in the browser world) are simply nuts. We simply shouldn't be terribly interested in re-creating this wart. I'm not sure I understand your point. Do

Re: Subclassing basic types in DOM - best method?

On Nov 20, 2012, at 8:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Nov 20, 2012 at 3:28 AM, Alex Russell a...@dojotoolkit.org wrote: Actually, looking at this IDL more closely, I see unneeded invariants causing most of the problem. If URLQuery subclasses Map (assuming we make

Re: Subclassing basic types in DOM - best method?

mind, reduce the utility of having actual JS-native types as the baseline from which we design/subclass over in DOM. -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: Subclassing basic types in DOM - best method?

the contents when calling getAll(). There's no reason to re-defined anything about Map here or prevent the normal Map methods from taking any/any as key/value pairs. That URLQuery might, in normal usage, behave this way is a decision for users of the API. On Tue, Nov 20, 2012 at 10:04 AM, Alex Russell

Re: Subclassing basic types in DOM - best method?

I think the basic issue here is that DOM is over-specifying the constraints (I assume because WebIDL makes that most natural?), not the available JS hacks to implement their weirdo type constraints. Lets not feed the misdesign trolls = ) On Tue, Nov 20, 2012 at 2:25 PM, Domenic Denicola

Re: Support for basic linear algebra on Array's

@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D

Re: no strict; directive

. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: no strict; directive

development. br On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell a...@dojotoolkit.orgwrote: On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: use strict is removed from code by default ... this is where it goes once minified: nowhere. I would rather force

Re: Promises

-- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promises

Sorry for ignoring the rest of this thread in my first reply, but I'll try to cover as much ground as I can here. Response inline: On Tue, Nov 6, 2012 at 6:47 PM, David Bruant bruan...@gmail.com wrote: Hi, In a post to public-script-coord yesterday, Alex Russel wrote the following [1]:

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

I agree (unsurprisingly) with Arv and Yehuda on this. Side effects are what make the world go 'round. Getting overly prescriptive here is just a way to box us into [not]using some particular stylistic form when designing API...and I don't see how that settles any interesting questions. I'd much

Re: ES transpilers

It would be helpful if that page listed licenses and minimum es target versions (es5? es3?) Regards On Oct 16, 2012, at 5:12 AM, Claus Reinke claus.rei...@talk21.com wrote: With ES6 engine compatibility still looking somewhat red http://kangax.github.com/es5-compat-table/es6/ transpilers

Re: New ECMAScript Internationalization API Specification draft

On Mon, Oct 15, 2012 at 7:44 PM, Norbert Lindenberg ecmascr...@norbertlindenberg.com wrote: The 12 October 2012 draft of the ECMAScript Internationalization API Specification is available at http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts and due to popular demand

Re: Public communication channels (was: Mootools and String.prototype.contains)

On Sat, Oct 13, 2012 at 12:34 PM, David Bruant bruan...@gmail.com wrote: 2012/10/12 Alex Russell slightly...@google.com I feel like there's as PSA we should write over on webplatform.org for library authors about how to not be future hostile. Some context for those who wouldn't have

Re: Mootools and String.prototype.contains

It's unclear what we should do here. Their test-and-install mechanism was overly optimistic and therefore future hostile. It looks as though outreach is happening and they're fixing their library and aligning with ES6 in future releases. My suggestion is to wait-and-see what browser vendor

Re: Mootools and String.prototype.contains

Good context. I didn't know that they had b0rked bind() as well ;-) I feel like there's as PSA we should write over on webplatform.org for library authors about how to not be future hostile. On Fri, Oct 12, 2012 at 3:26 PM, Geoffrey Sneddon gsned...@opera.comwrote: On 12/10/12 14:50, David

Re: Map/Set.prototype.size

+1 On Fri, Oct 12, 2012 at 4:19 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: +1 On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com wrote: Hi, Firefox has implement a Map/Set.prototype.size *method* to query the number of mapping/elements. It's not in the

Re: Cross-frame symbols

It's unclear how we could possibly do this for anything but built-ins, and even there it's iffy. What if someone extends you builtin's prototype in one frame but not the other? Anyhow, this all bottoms out at object identity. Functions are objects, and declaring identically named objects in

Re: Sept 20 TC39 Meeting Notes

and SpiderMonkey and other engines. I'd prefer just bound so we can stop pretending there's a soft option. -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es

Re: exporting a class

On Sep 26, 2012 11:10 AM, Brandon Benvie bran...@brandonbenvie.com wrote: Is it correct that there's no way to export a class declaration? The best I can see is something like module Geometry { export let Point = class Point { .. } Just use: export class Point { .. } }

Re: Optional argument types

On Tue, Sep 25, 2012 at 8:54 PM, Brendan Eich bren...@mozilla.org wrote: Andrea Giammarchi wrote: then how about forgetting ducks and classes, going typeof without implicit cast? No. Why the desperation to get something -- *anything* -- even a half-baked idea based on broken old typeof?

Re: exporting a class

+dherman It seems this hasn't been updated to account for the class binding form. What I wrote should work, though, and it'll be a bug in the spec if it doesn't. On Wed, Sep 26, 2012 at 1:16 PM, Brandon Benvie bran...@brandonbenvie.comwrote: The reason I ask is because the only grammar

Re: Optional argument types

On Wed, Sep 26, 2012 at 1:06 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: surely there's nothing to rush about, we survived already until now, no reason to go for a quick solution and mine was just a proposal based on the fact that most of the time contracts are based on

Re: Optional argument types

It's far too early to tell. I strongly prefer structural, but again, backing a type system into ES isn't something to do lightly. It has huge consequences that extend well beyond the grammar changes. On Tue, Sep 25, 2012 at 3:59 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: then

Re: Feed back and proposal for modules: allow importing ES5 files

to get more feed back :-) This is interesting. Do you have a proposed resolution mechanism for conflicts? We had such a thing in the old traits system for classes, but I don't think it has survived anywhere. -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org

Re: Feed back and proposal for modules: allow importing ES5 files

Hi Shaofei: Inline: On Mon, Sep 24, 2012 at 7:22 AM, 程劭非 csf...@gmail.com wrote: Thank you for replying, Alex. Replied inline. 2012/9/24 Alex Russell a...@dojotoolkit.org: Hi Shaofei: On Sep 22, 2012, at 6:29 PM, 程劭非 csf...@gmail.com wrote: Hi, everyone, I noticed

Re: Function#fork

Let me put bounds on this, then: Approaches that enable shared mutable state are non-starters. A send based-approach might work (e.g., Worker Tranferrables) as might automatic parallelization (e.g., RiverTrail) -- but threads and thread-like semantics aren't gonna happen. Turn-based execution

Re: Object.observe and observing computed properties

On Wed, Aug 29, 2012 at 11:09 AM, Steve Sanderson fla...@gmail.com wrote: Hey Thanks very much for your detailed response! I totally agree that the question can be distilled down to deciding when [a] function should be re-evaluated, and that two approaches are 2a: requiring function author

Re: Convergence options for Ecmascript/Actionscript?

What Brendan said. Let me just add this: Flash isn't about AS3 (particularly). It's an entire environment, event model, rich library of APIs, and a deep toolchain that allows developers to be productive. Even if we were to adopt the (foolish) goal of adding missing AS3 features to ES, that

Re: Convergence options for Ecmascript/Actionscript?

On Wed, Aug 29, 2012 at 10:05 AM, Claus Reinke claus.rei...@talk21.comwrote: Since this seems to be open to misinterpretation: I'm looking at this from a JS developer perspective, and since ES4 failed, I was *not* asking to make ES6 any more like AS3. What I thought would be interesting can

Re: Re: Experimental implementation of Object.observe JS Utility library now available

On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie bran...@brandonbenvie.comwrote: I would say it is most definitely not the concern of Observe to watch reads and between accessors and Proxies we have all the tools we need for that. I think that misreads the situation. Having proxies available

Re: Experimental implementation of Object.observe JS Utility library now available

The core improvement for Object.observe() here is that instead of delivering *nested* changes, unrolling of observers happens one after the other. The design of the system never puts observers on the stack on top of each other, meaning that whatever happens as a result of code you happen to call

Re: Experimental implementation of Object.observe JS Utility library now available

On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: just seen it, looks like an improved alternative to the good old, non standard, Object.prototype.watch Key differences include: * unlike watch(), you can be informed not only of deletions but also

Re: What’s the best name for keyword parameters?

-parameters.html -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: ES Modules: suggestions for improvement

Strongly concur with Andreas. Citing Java is fraught beyond belief. Andreas Rossberg rossb...@google.com wrote: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Why not NodeList#forEach :\?

On Jun 11, 2012, at 11:46 AM, David Bruant wrote: Hi, Le 11/06/2012 12:30, Hemanth H.M a écrit : [].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an [] ? I've written a section on MDN specifically a while ago to answer that very question:

Re: A few arrow function specification issues

-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Arrow binding

.call() and .apply() to be savvy to preferences, but this doesn't seem particularly painful. I've bluntly worked around it in this example to avoid __proto__ re-wiring. Thoughts? -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259

Re: Arrow binding

On Mon, Apr 23, 2012 at 2:47 PM, Russell Leggett russell.legg...@gmail.com wrote: On Mon, Apr 23, 2012 at 6:53 AM, Alex Russell a...@dojotoolkit.org wrote: Despite making repeated arguments for soft binding, I'm pretty sure I haven't outlined here what it actually would *be*. Now that we're

Re: Arrow binding

johnjbar...@johnjbarton.com wrote: On Mon, Apr 23, 2012 at 3:53 AM, Alex Russell a...@dojotoolkit.org wrote: The new forms we're adding (methods and arrows) have the potential to change this radically, causing a large percentage of functions encountered by programmers to have binding

Re: Arrow binding

On Apr 23, 2012, at 3:30 PM, Russell Leggett wrote: That is only true for functions that actually use |this|. Even though bind is probably not used in force yet because of cross-browser worries, var self = this is used everywhere. Functions using that pattern are no more usable with

Re: Finding a safety syntax for classes

On Mar 21, 2012, at 1:42 AM, Erik Arvidsson wrote: On Mon, Mar 19, 2012 at 13:03, Russell Leggett russell.legg...@gmail.com wrote: So what do you say people? Is it safe enough? Yes. One of the biggest arguments I’ve heard against rushing in a class syntax now is that once its in we have

Re: Finding a safety syntax for classes

Sorry I'm late to this party. On Mar 20, 2012, at 6:22 PM, Russell Leggett wrote: On Tue, Mar 20, 2012 at 2:09 PM, Rick Waldron waldron.r...@gmail.com wrote: [ ... snip ] class Animal { constructor(name){ this.name = name; } move(meters){

Re: Classes: Moving away from object literal syntax

___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: Sep 27 meeting notes

On Oct 3, 2011, at 9:57 PM, Brendan Eich wrote: On Oct 3, 2011, at 8:26 PM, Waldemar Horwat wrote: On 09/30/2011 08:43 PM, Brendan Eich wrote: On Oct 1, 2011, at 5:24 AM, Brendan Eich wrote: On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote: There are lots of ways to do classes that

Re: Function.create

/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: IDE support?

all the errors that that produces. Again, that is undecidable in general, due to Javascript's flexibility, though approximations will be useful. Claus (who'd love to work on JS-in-JS tooling;-) http://clausreinke.github.com/ -- Alex Russell slightly...@google.com slightly...@chromium.org

Re: IDE support?

-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: Pure win: Array.from and Array.of

-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es

Re: Is class syntax really necessary ?

? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: Is class syntax really necessary ?

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 -- Alex Russell slightly...@google.com slightly...@chromium.org

Re: Is class syntax really necessary ?

On May 23, 2011, at 10:41 AM, Brendan Eich wrote: On May 23, 2011, at 10:03 AM, Alex Russell wrote: (A) the boilerplate needed to set up a sub-prototype object with correct constructor property, and (B) the pain of doing correct super calls by hand. I hope we can add the hazards

Re: Short Functions

, and continue from blocks all the time. I think you're over-playing the use of blocks in the syntactic sense. My observation has been that when people use them, it's primarily accidental. Citing that feels like weak ground to argue from. -- Alex Russell slightly...@google.com slightly

Re: That hash symbol

@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https

Re: Additional language features

priority to me as the rest of the binary data spec. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB

Re: [whatwg] Cryptographically strong random numbers

___ 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 -- Alex Russell slightly...@google.com slightly

Re: New private names proposal

/listinfo/es-discuss -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

  1   2   >