On Jan 15, 2009, at 7:25 AM, Anne van Kesteren wrote:
On Thu, 15 Jan 2009 14:16:04 +0100, Pratap Lakshman (VJ#SDK) prat...@microsoft.com
wrote:
I have uploaded to the wiki (linkhttp://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
) the 15 Jan 2009 draft of the
yep. My bad. Sorry all.
On Jan 15, 2009, at 10:29 AM, Brendan Eich wrote:
On Jan 15, 2009, at 9:43 AM, Anne van Kesteren wrote:
On Thu, 15 Jan 2009 18:40:29 +0100, Alex Russell a...@dojotoolkit.org
wrote:
On Jan 15, 2009, at 7:25 AM, Anne van Kesteren wrote:
FWIW, it seems
://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
- --
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-BEGIN PGP SIGNATURE-
Version
security. However, I have no clever ideas
of what
such tighter language should say. Suggestions appreciated.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
- --
Alex Russell
slightly
resources to elide away first-run compilation or
in other ways apply more processor power to generating better/faster-
starting code.
Regards
- --
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-BEGIN PGP SIGNATURE-
Version
On Jul 3, 2009, at 1:21 AM, Christian Plesner Hansen wrote:
Likewise, for user-defined function foo, foo.prototype is writable
-- but
not so for built-in constructor functions, and not so for classes
as sugar
(more below).
All JS code currently in existence is based on user-defined
their language.
In short, it helps Harmony classes make all of the same mistakes that
DOM host objects currently plague developers with.
Regards
- --
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-BEGIN PGP SIGNATURE-
Version
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242
On Dec 4, 2009, at 1:52 PM, Mike Samuel wrote:
2009/12/4 Alex Russell a...@dojotoolkit.org:
On Dec 4, 2009, at 9:38 AM, Mark S. Miller wrote:
On Fri, Dec 4, 2009 at 8:41 AM, Alex Russell
a...@dojotoolkit.org wrote:
CommonJS modules don't solve the global pollution problem,
because
On Dec 4, 2009, at 2:13 PM, Brendan Eich wrote:
On Dec 4, 2009, at 2:11 PM, Alex Russell wrote:
me: the problem is that people can still omit var
you: everyone will run it through a verifier
me: programmers are still human, particularly web developers. They
don't run verifiers. In general
Some small, pre-colored panels for the shed. Given that these are
mostly matters of syntax and not semantics, please believe me when I
suggest that the warts discussed herein present sharp edges that
should be rounded off by the committee -- not because they're
interesting in any way but
On Thu, Apr 29, 2010 at 11:51 AM, Mark S. Miller erig...@google.com wrote:
On Thu, Apr 29, 2010 at 12:25 AM, Alex Russell a...@dojotoolkit.org wrote:
node.addEventListener(click, bang(obj, method));
// works!
node.removeEventListener(click, bang(obj, method));
On Thu, Apr 29, 2010 at 10
On Thu, Apr 29, 2010 at 10:03 AM, Brendan Eich bren...@mozilla.com wrote:
On Apr 29, 2010, at 12:25 AM, Alex Russell wrote:
Some small, pre-colored panels for the shed. Given that these are mostly
matters of syntax and not semantics, please believe me when I suggest that
the warts discussed
On Apr 29, 2010, at 7:55 PM, Douglas Crockford wrote:
On 11:59 AM, Brendan Eich wrote:
On Apr 29, 2010, at 4:33 PM, Mark S. Miller wrote:
On Thu, Apr 29, 2010 at 2:40 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
The JSConf audience poll did provoke someone to
functionality defined elsewhere in
the library. This is then not necessarily the right way to implement it
natively.
Jürg
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly
--
erik
--
Alex Russell
slightly...@google.com
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
array subclass leaves the constructor
non-configurable and read-only isn't much of a trick in ES5. That said, why
*doesn't* TypedArray spec a mutable variant? Surely it'd be useful.
Regards
--
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3
On May 13, 2010, at 11:09 PM, Oliver Hunt wrote:
On May 13, 2010, at 10:21 PM, Alex Russell wrote:
On May 13, 2010, at 5:15 PM, Vladimir Vukicevic wrote:
This is difficult to do, given the goals of typed arrays -- they wouldn't
behave like normal Arrays in most meaningful ways
will suffer.
If we only provide primitives all js libraries will have to
reimplement a usable abstraction layer. This is leads to more code
which leads to higher latency and slower application.
+1. What Erik said.
--
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03 E88D EABB 2116
hope we can move this from strawman into
proposals at the next face to face meeting.
Agreed, this looks really strong. I particularly like the local renaming
ability. I hope this can be discussed and adopted very quickly.
Regards
--
Alex Russell
slightly...@google.com
a...@dojotoolkit.org BE03
)); // parens - no return
let myfun = \(x) (x * x);
Also, is anything proposed for rationalizing ASI in Harmony.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
On Jul 24, 2010, at 12:45 PM, Brendan Eich wrote:
On Jul 24, 2010, at 12:39 PM, Alex Russell wrote:
On Jul 24, 2010, at 12:27 PM, Brendan Eich wrote:
On Jul 24, 2010, at 11:00 AM, Alex Russell wrote:
On Jul 24, 2010, at 9:21 AM, Kevin Curtis wrote:
Should the proposed shorter form
than 3 minutes to implement in JS in
any current UA.
-it would just need to be in the ES specs.
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
On Oct 2, 2010, at 10:45 AM, Alex Russell wrote:
On Oct 2, 2010, at 6:49 AM, Jorge wrote:
On 02/10/2010, at 15:29, Brendan Eich wrote:
On Sep 6, 2010, at 1:43 AM, Dmitry A. Soshnikov wrote:
For what to create a proxy? It's only for catch-traps (yes, it may be used
additionally
-
___
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
/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
On Dec 21, 2010, at 10:14 PM, Brendan Eich wrote:
On Dec 21, 2010, at 10:03 PM, Alex Russell wrote:
This is not a relevant fear in my view. It's also kind of silly given all
the open source JS libraries. If someone did over-freeze, you could stop
using their library, or fork and fix
___
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
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
@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
, 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
?
/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
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
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
-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
___
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
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
/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
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
___
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
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
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){
-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
.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
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
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
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
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:
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
-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
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
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
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
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
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
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
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
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
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
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
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 { .. }
}
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?
+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
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
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
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
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
+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
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
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
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
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
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
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]:
--
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
.
/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
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
@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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
1 - 100 of 127 matches
Mail list logo
