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 week's TC39 meeting.
>
>
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
tha
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
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" wrote:
> JSIL has a shim that emulates the 2D portion of the
Is there seriously going to be no attempt whatsoever to moderate this list?
On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L 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 the let, and const s
mon 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 Russell
> wrote:
>
>> Right. Would love to know the size/traffic of the "number of site
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
wrote:
>
>
>
> On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich
> wrote:
>
>> Would .items fare better, I wonder.
>>
>
> Or outreach to sites the break?
>
> Rick
>
>
>>
>
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
wrote:
> On Sun, Apr 6, 2014 at 1:41 PM, Allen Wirfs-Brock
> wrote:
> > The April 5, 2014 ECMAScript 6 Draft Specification (Rev23
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich 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.)
>
> Let's
On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg wrote:
> On 19 December 2013 23:29, Alex Russell 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, I
> >
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 Kosev
On Thu, Dec 19, 2013 at 9:24 AM, Mark S. Miller 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
> doesn't break exi
On 18 Dec 2013 20:27, "Ѓорѓи Ќосев" wrote:
>
> On 12/19/2013 02:56 AM, Alex Russell wrote:
>>
>> On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев
wrote:
>>>
>>> I understand that adding branding to promises is impossible at this
>>> point, as
On 18 Dec 2013 18:20, "Andrea Giammarchi"
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
have given rough consensus
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев 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 have
a-priori comp
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
On Thu, Dec 12, 2013 at 9:40 AM, Brendan Eich wrote:
> Kevin Smith wrote:
>
>> My thoughts:
>>
>> Again, generators are not a good fit for arrows - generators define
>> sequences, not mappings.
>>
>
> Yep.
>
>
> Secondly, we should be conservative in our usage of arrow-like operators
>> - we onl
On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker wrote:
> On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee 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 an ECMAscript processo
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 wrote:
> To do this, I think the draft requires these changes:
>
> - Remove the trailing section of section 1.2, starting with “ECMAscript
> 5.1 enumerates...”
On 3 Oct 2013 08:23, "Yusuke SUZUKI" 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 said that Promises wi
"Defend against everything" is a security non sequitur. If you want this
group to consider specific areas to lock down, we need to understand
specific threat models.
Le 26/09/2013 20:14, Alex Russell a écrit :
On Thu, Sep 26, 2013 at 9:56 AM, Aymeric Vitte wrote:
> I would l
7;t
> understand very well what 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 Se
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" wrote:
> This is similar to the "Native" thread as Andrea mentioned.
>
> Then when SES is coming?
>
> It seems urgent to boost it, I have tried CSP recent
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 create
On Wednesday, May 1, 2013, Tab Atkins Jr. wrote:
> On Tue, Apr 30, 2013 at 9:43 AM, Claus Reinke
> >
> wrote:
> > The promises-aplus spec has a note that confuses me
> >
> >https://github.com/promises-aplus/promises-spec#notes
> >
> >1. In practical terms, an implementation must use a mec
On Wednesday, May 1, 2013, Jonas Sicking wrote:
> On Mon, Apr 29, 2013 at 6:57 PM, Ron Buckton
> >
> 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
> > be found here:
> >
> >
> >
t; lost when using Future.any, etc.
>
> ** **
>
> My intent currently is not to advocate any of these approaches. Rather;
> I’m trying to catalogue each approach as I’ve come across them specifically
> to gather this kind of feedback.
>
Much appreciated. I've fre
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 t
On Friday, April 26, 2013, Tab Atkins Jr. wrote:
> On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell
> >
> wrote:
> > On Apr 26, 2013 8:33 PM, "Tab Atkins Jr."
> > >
> wrote:
> >> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith
> >>
>
On Apr 26, 2013 8:33 PM, "Tab Atkins Jr." wrote:
>
> On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith
wrote:
> > Actually, I may have gotten it terribly wrong (apologies). In my
prototype
> > implementation, the following:
> >
> > Future.accept(Future.resolve(1)).then(value => {
> >
> >
Yes, you do.
On Apr 26, 2013 2:54 PM, "Kevin Smith" 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 not the API
On Apr 22, 2013 5:29 PM, "Mark S. Miller" 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 cohabit
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" wrote:
> On Mon, Apr 22, 2013 at 5:37 AM, David Bruant wrote:
>
>> Le 22/04/2013 14:
Hi Ron,
Comments inline.
On Wed, Apr 17, 2013 at 7:35 PM, Ron Buckton wrote:
> 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:
>
> https://gist.github.com/rbu
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant wrote:
> Le 18/04/2013 09:40, Anne van Kesteren a écrit :
>
>> On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr.
>> wrote:
>>
>>> Note that Futures are entirely expressible in today's JS semantics.
>>>
>>> (Not to say that it shouldn't be reviewed by t
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 wrot
On Friday, April 12, 2013, Rick Waldron wrote:
>
>
>
> On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell
>
> > wrote:
>
>> On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon
>>
>> > wrote:
>>
>>> On 09/04/2013 16:51 , Brendan Eich wrote:
&g
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon 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 spec-work
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
>
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
and
On Thursday, February 14, 2013, Andreas Rossberg wrote:
> On 14 February 2013 19:26, Herby Vojčík >
> 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
> > learned to write `foo.ba
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 t
On Tuesday, January 8, 2013, Tab Atkins Jr. wrote:
> On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
> > wrote:
> > So, I am playing with FF 18 and I have this behavior:
> >
> > var a = new Proxy([], {});
> > console.log(a instanceof Array); // true
> > console.log(Array.isArray(a)); // true
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
> >
> wrote:
> > If down the road we want to allow for the theoretical possibility of
> > having all platform APIs implemented in JavaScript, we might wan
+1. What Andreas said.
On Friday, December 14, 2012, Andreas Rossberg wrote:
> On 13 December 2012 19:21, Mark S. Miller >
> wrote:
> > On Thu, Dec 13, 2012 at 1:12 AM, David Bruant
> > >
> wrote:
> >>> As you say, to remain viable, it
> >>> must be done quickly. From previous experience, I sugg
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
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
On Nov 20, 2012, at 8:08 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 20, 2012 at 3:28 AM, Alex Russell wrote:
>> Actually, looking at this IDL more closely, I see unneeded invariants
>> causing most of the problem. If URLQuery subclasses Map (assuming we make
>> this poss
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 <
dome...
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 A
h proxies, or
a subclass that simply over-writes the set methods to blow up on on-strike
key/value setting. Either way, it doesn't seem particularly difficult and
doesn't, to my mind, reduce the utility of having actual JS-native types as the
baseline from which we desi
modules, with a principled
> approach to avoiding adding support for * to arbitrary other code. Lexically
> scoped operators, perhaps as hygienic macros a la a future sweetjs.org
> approach (infix operator macros are on the agenda there, not yet supported),
> is the way to go.
&
ling ... those days are gone in modern JS development.
>
> br
>
>
> On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell wrote:
>
>> On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> > "use strict" is remove
s's abuses of 'with' are
>> unjustified. Yes, "be water". Yes, masters may break rules students must
>> follow. None of that philosophizing justifies 'with' abusage or
>> repealing/undoing "use strict".
>>
>> /be
>>
&g
;
> Regards,
>
> - Leo
>
> ___
> 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 wrote:
> Hi,
>
> In a post to public-script-coord yesterday, Alex Russel wrote the
> following [1]:
> "[Web]IDL *is ha
This use-case is usually what weak refs get pressed into service for. But I
think that answering your question, "why is my RSS continually increasing?"
is something for a tool (debugger, profiler, etc.) to help answer. Some
sort of assertion version of free() seems like the right thing: it can
comm
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
rat
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 dem
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 wrote:
>
> With ES6 engine compatibility still looking somewhat red
>
> http://kangax.github.com/es5-compat-table/es6/
>
> transpilers are not just a use
On Sat, Oct 13, 2012 at 12:34 PM, David Bruant wrote:
> 2012/10/12 Alex Russell
>
>> 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
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 differ
+1
On Fri, Oct 12, 2012 at 4:19 PM, Erik Arvidsson wrote:
> +1
>
> On Fri, Oct 12, 2012 at 11:16 AM, David Bruant wrote:
> > Hi,
> >
> > Firefox has implement a Map/Set.prototype.size *method* to query the
> number
> > of mapping/elements.
> > It's not in the strawman. It appears in the latest
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 wrote:
> On 12/10/12 14:50, David Bruant wrote:
>
>> I
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 advocac
caller anywhere
It's demonstrably the same overhead as hard binding.
> -- this won't fly with V8 and SpiderMonkey and other engines.
>
> I'd prefer just "bound" so we can stop pretending there's a "soft&q
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 primi
+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
wrote:
> The reason I ask is because the only grammar reference I could find was at
>
On Tue, Sep 25, 2012 at 8:54 PM, Brendan Eich 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? Where'
On Sep 26, 2012 11:10 AM, "Brandon Benvie"
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 { .. }
> }
>
> __
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
Perhaps, but it's easy to be too naive about what VMs do (and don't do).
Best to design for semantics with performance in mind, not the other way
around.
In any case, would you be looking for nominal or structural type tests here?
On Sep 25, 2012, at 11:44 AM, Andrea Giammarchi
wrote:
... or th
I think module loaders would, indeed help, although as you point out,
you're gonna need some sort of transformation step and we don't provide an
AST to work against. You might need something like Traceur's front-end or
esprima to get started on a reliable transform pass. But yeah, doable.
On Mon,
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 wi
Hi Shaofei:
Inline:
On Mon, Sep 24, 2012 at 7:22 AM, 程劭非 wrote:
> Thank you for replying, Alex.
>
> Replied inline.
>
> 2012/9/24 Alex Russell :
> > Hi Shaofei:
> >
> > On Sep 22, 2012, at 6:29 PM, 程劭非 wrote:
> >
> >> Hi, everyone,
> >>
, for example, if I'm using a RSA library like
> <http://www-cs-students.stanford.edu/~tjw/jsbn/>, I can do the
> following:
>
>
> import "jsbn.js","prng4.js","rng.js","rsa.js" as RSA;
>
> If I want to use a module depend on jQue
Once upon a time we actually had Traits in the pre-maxmin-classes
implementation in Traceur. We've removed it as the class proposal is now
radically different, but I'm hopeful that once classes are "baked", traits
will be one of the important improvements we can add quickly.
Getting there requires
On Wed, Aug 29, 2012 at 11:09 AM, Steve Sanderson 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
> to decla
On Wed, Aug 29, 2012 at 10:05 AM, Claus Reinke wrote:
> 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 be reduced to two
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 wouldn
On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie
wrote:
> 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 might work
for this, bu
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 wi
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
ad
ptions objects”. Hence keyword parameter = option? But that clashes
>>> a bit with optional positional parameters.
>>>
>>> [1] http://www.2ality.com/2011/11/keyword-parameters.html
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03
Strongly concur with Andreas. Citing Java is fraught beyond belief.
Andreas Rossberg wrote:
>___
>es-discuss mailing list
>es-discuss@mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss m
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:
> https://dev
On Apr 23, 2012, at 3:35 PM, Mark S. Miller wrote:
> On Mon, Apr 23, 2012 at 6:46 AM, Kevin Smith wrote:
> I'm not sure I understand the reasoning behind "soft-binding". If I use
> arrow syntax, my intention is to close over |this|.
Arrow will take on whatever meaning we decide for it to take
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
> > usabl
wrote:
>
>
> On Mon, Apr 23, 2012 at 3:53 AM, Alex Russell 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 bind
On Mon, Apr 23, 2012 at 2:47 PM, Russell Leggett
wrote:
>
>
> On Mon, Apr 23, 2012 at 6:53 AM, Alex Russell wrote:
>>
>> Despite making repeated arguments for "soft binding", I'm pretty sure I
>> haven't outlined here what it actually would *be*. N
objects and they do today).
Here's a JSFiddle with an a quick ES5 desugaring + example:
http://jsfiddle.net/slightlyoff/739CS/20/
Note that we need to re-define .call() and .apply() to be savvy to preferences,
but this doesn't seem particularly painful. I've bluntly worke
;t special-case if there is no strong reason to
> do so.
>
>
>> 7) All of the above questions also apply to functions defined using concise
>> method syntax in object literals or classes. Should the same answers apply
>> to them?
>
> I'd prefer if concise
t; It's messy, but emphasizes that the important thing is what the function
> depends upon rather than which syntactic form was used to define it.
>
> Allen
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla
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 wrote:
> [ ... snip ]
> class Animal {
>
> constructor(name){
>
> this.name = name;
>
> }
>
> move(meters){
>
> alert(this.nam
On Mar 21, 2012, at 1:42 AM, Erik Arvidsson wrote:
> On Mon, Mar 19, 2012 at 13:03, Russell Leggett
> 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
>> to keep supporti
twitter.com/rauschma
> blog: 2ality.com
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotool
gt; twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromiu
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
>>> wiki page mentionning these two functions somewhere? If not, may it be
>>> added and linked in some way to the proto operator?
>>>
>>> David
>>>
>>> [1] http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator
>>>
t
> have to push to github, figure out pull requests and submodules, and
> write a blog post to explain the whole thing..
>
>> - Find all invocations of a method/function. Often, I just change the
>> name of a method (e.g. by appending an "x") and go through all the
>&
1 - 100 of 149 matches
Mail list logo
