Le 14/10/2013 18:21, Jorge Chamorro a écrit :
On 14/10/2013, at 17:20, David Bruant wrote:
How much are we trying to save with the bundling proposal? 200ms? 300ms? Is it
really worth it? I feels like we're trying to solve a first-world problem.
I think that the savings depend very much
Le 13/10/2013 20:29, Benjamin (Inglor) Gruenbaum a écrit :
David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote
This proposal does not aim at solving the problem of library
conflicts which existed before this proposal and should be solve
independently.
Of course, and I'm sorry
loader?
Not sure if this changes anything, carry on.
- Russ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David Bruant mailto:bruan...@gmail.com
October 11, 2013 4:23 AM
Le 11/10/2013 12:46, Jorge
Le 11/10/2013 03:10, Andrea Giammarchi a écrit :
You are confining the problem in HTTP only scenarios while the
solution provided by
script src=lib/main.js ref=”assets.zip”/script
can be handy/reused in offline packaged applications too so HTTP 2
might win on HTTP but it's not a general HTML
Le 11/10/2013 12:46, Jorge Chamorro a écrit :
On 11/10/2013, at 12:02, David Bruant wrote:
Providing a zip in the manifest file could work, but I'm not sure I see the
benefit over individual files. Disk fragmentation issues maybe?
One benefit is that a single .zip can fetch a bunch of files
Le 11/10/2013 15:15, Russell Leggett a écrit :
Just wanted to point out a couple of previous attempts at something
similar to generic bundling and the reactions it got, because so far
it hasn't panned out.
Way back in 2008, it was my one and only real contribution to the
whatwg list before
Le 11/10/2013 15:51, Russell Leggett a écrit :
Not sure if this changes anything, carry on.
Server push is happening as part of HTTP 2.0. Do you have a use
case in which it's insufficient?
Not sure if this was directed at me or Jorge
To anyone really, trying to understand if
Le 11/10/2013 19:01, Andrea Giammarchi a écrit :
As I've said, you keep confining the problem and the solution over
HTTP and servers while I see this approach, maybe slightly revisited,
a good **generic bundling** solution even without a server and easily
adoptable now plus this will not mean
HTTP 2 is coming with a feature called server-push [1] which seems more
appropriate for this type of bundling.
In essence, when being asked for a webpage, the server sends the HTML
page as well as a bunch of resources (CSS, JS, image, whatever) in the
same HTTP response. These are individually
Hi,
The question of thenables came back on Mozilla's Bugzilla [1] (see
comment 29 30) with a decent share of skepticism that I share too.
I'm sorry I didn't go through all the promises discussions, but what's
the rationale of supporting thenables? I fear this feature won't be
necessary 2
Le 02/10/2013 04:35, Andrea Giammarchi a écrit :
setTimeout accept extra arguments ... I write JavaScript that uses
this feature.
`setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`
What is evenAnObject? It doesn't look like a standard thing:
Le 02/10/2013 19:45, Andrea Giammarchi a écrit :
so fat arrow does not solve much here, I can use self as first
argument and I am good.
`forEach` and all other arrays accept a second argument
`array.forEach(doStuff, boundContextObject);`
so fat arrow
Le 30/09/2013 19:30, Rick Waldron a écrit :
On Mon, Sep 30, 2013 at 12:54 PM, Kevin Smith zenpars...@gmail.com
mailto:zenpars...@gmail.com wrote:
I think all we want here is make HTMLCollection interoperate
better
with other lists. For new features we moved away from
Le 27/09/2013 17:57, Anne van Kesteren a écrit :
On Fri, Sep 27, 2013 at 11:53 AM, Mark S. Miller erig...@google.com wrote:
The structured cloning algorithm is the last thing I want to use to
communicate between workers. I advise avoiding it like the plague, instead
serializing to JSON, sending
Le 26/09/2013 00:48, Aymeric Vitte a écrit :
It's not easy to freeze the world like Caja is doing, and it's not
easy to have a library that takes care of it securely
Good thing Caja is open source, right? ;-)
In the case Michaël Rouges seems to describe, it can be enough to do
that at
Le 26/09/2013 09:10, Aymeric Vitte a écrit :
There are other cases, like malicious code injection.
CSP goes a long long way in preventing these.
I don't know if it's really feasible without redefining the DOM on top
of it but I feel the need since a long time, something that makes sure
you
Le 26/09/2013 01:29, François REMY a écrit :
Hi,
TLDR == The web needs a way to express executable code that does not rely on
its parent context, is guaranteed to be side-effect-free, and can be executed
safely anywhere (even in a different thread/worker/window/device, or as callback
for
Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit :
For those interested I provided in the CSP thread a link to a FF bug
report where it's explained how some security policy (here Websocket
spec) forces me to do insecure things. I don't know what list can take
care of it, there is a
Le 26/09/2013 12:16, Aymeric Vitte a écrit :
Le 26/09/2013 11:43, David Bruant a écrit :
Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit :
For those interested I provided in the CSP thread a link to a FF bug
report where it's explained how some security policy (here Websocket
spec
Le 26/09/2013 14:44, Anne van Kesteren a écrit :
On Thu, Sep 26, 2013 at 12:22 AM, Brendan Eich bren...@mozilla.com wrote:
Boris Zbarsky wrote:
The web _does_ in general rely on being able to apply methods from some
built-in (including DOM) prototype in one realm to objects from another
realm.
Le 26/09/2013 15:36, Bradley Meck a écrit :
The only really think of that would be of benefit is parallel execution.
MongoDB MapReduce exploits parallelism as much as one can ever hope and
just a string generated from
var f = '' + function(){...}
seems to work just fine.
(this actually
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and
we have not been able to
Le 25/09/2013 12:01, David Bruant a écrit :
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected
Le 25/09/2013 15:49, Mark S. Miller a écrit :
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal
state that doesn't need to be private: just name it with a unique symbol?
yes (assuming unique symbols are a
Le 25/09/2013 17:59, Allen Wirfs-Brock a écrit :
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
I think it's important to have a generic solution to avoid having
magic (non-self-hostable) built-ins (but I don't have this solution).
I don't think there is one, based upon Direct Proxies
Le 25/09/2013 22:00, Boris Zbarsky a écrit :
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
Le 25/09/2013 17:41, Michaël Rouges a écrit :
Hi all,
Given the number of scripts from various sources that may be contained
in a web page, there may be prototypingconflicts.
Be careful about what you include? To be proactive in that process,
freeze all builtins beforehand. You'll know soon
Le 19/09/2013 10:53, Tom Van Cutsem a écrit :
2013/9/18 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
... I just realized that in your examples, the private state is
stored in a weakmap which requires target identity. If I recall,
the original problem wasn't so much
Le 20/09/2013 13:02, Tom Van Cutsem a écrit :
2013/9/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I'm still inclined to think a generic solution to private state
and proxies should be found. Given this solution, the invoke trap
may end up being plain redundant
Le 17/09/2013 15:36, Jason Orendorff a écrit :
* improved performance for proxies, because method calls go through
one proxy handler trap rather than two, and no temporary function
object is allocated
The performance argument is a non-starter
Why? (damned! how do I find myself defending invoke
Le 18/09/2013 20:52, Tom Van Cutsem a écrit :
2013/9/18 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
An alternative to p3 and p4 would be to find a solution for the
interaction between private state and proxies that also works with:
Date.getMonth.call(myProxy
Le 13/09/2013 09:19, Tom Van Cutsem a écrit :
2013/9/12 Mark S. Miller erig...@google.com mailto:erig...@google.com
Membranes need shadow targets, because of non-extensibility of
objects and non-configurability of properties. This special case
of no-invariants-anywhere is not
Le 12/09/2013 15:35, Mark S. Miller a écrit :
On Thu, Sep 12, 2013 at 4:14 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
[+markm, allenwb]
But more generally, you're right that it's odd [[GetInheritance]]
is doing an invariant check on an otherwise
Le 11/09/2013 06:10, Boris Zbarsky a écrit :
Hey all,
I was looking at implementing a membrane using ES6 proxies and ran
into a snag. Consider a situation where object A has prototype B. A'
is a proxy implementing the membrane, whose target is A.
But now if Object.getPrototypeOf(A') is
Le 11/09/2013 06:10, Boris Zbarsky a écrit :
I was looking at implementing a membrane using ES6 proxies
May I ask why you've been working on that? Is it related to the work on
WebIDL binding of DOM/browser objects?
One design goal of proxies was getting closer to self-hostability of the
Le 11/09/2013 16:22, Tom Van Cutsem a écrit :
2013/9/11 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I think it was discussed at some point to get rid of the
restriction on the getPrototypeOf trap and enforce it only for
non-extensible objects (but I can't find the info
Le 11/09/2013 16:52, Boris Zbarsky a écrit :
One design goal of proxies was getting closer to self-hostability of the
DOM/browser APIs
Yeah, I was basically thinking about how I'd do Gecko's cross-global
wrappers with ES proxies (not that that's a reasonable thing to do,
since it requires
Le 11/09/2013 17:45, Boris Zbarsky a écrit :
On 9/11/13 11:23 AM, David Bruant wrote:
Can you elaborate on these APIs?
In particular, the API that changes the current global and effective
script origin. That clearly can't be done from a script, since the
global and effective script origin
Le 11/09/2013 17:51, Allen Wirfs-Brock a écrit :
Ps: btw, wasn't GetInheritance supposed to be renamed
GetPrototype?
I think we had agreement on that. Allen?
I'm willing to call them [[GetPrototypeOf]] and [[SetPrototypeOf]] to
match the trap names. I prefer avoiding a direct
Le 08/09/2013 21:39, Brendan Eich a écrit :
In no case does anyone that I've spoken to, on TC39 or anywhere else
around this planet, want *yet another* bottom type and singleton value
a la null and undefined. No one. Those who speak Spanish and nearby
languages tend to say ¡Basta! -- I'm not
Le 09/09/2013 11:41, Claude Pache a écrit :
Le 9 sept. 2013 à 10:35, David Bruant bruan...@gmail.com a écrit :
Le 08/09/2013 21:39, Brendan Eich a écrit :
In no case does anyone that I've spoken to, on TC39 or anywhere else around this planet,
want *yet another* bottom type and singleton
Le 06/09/2013 18:06, Brendan Eich a écrit :
Domenic Denicola mailto:dome...@domenicdenicola.com
September 6, 2013 8:48 AM
What is the value of allowing you to send in values via `.next(v)`,
or send in exceptions via `.throw(e)`?
An iterator does not reject .next calls that pass a value.
fair
Le 06/09/2013 17:39, Brendan Eich a écrit :
Brandon Benvie wrote:
I don't think you're missing anything. They seem to be more
accurately described as Iterator Expressions than Generator
Expressions. It might be interesting if you could use yield inside
them, which would then make sending a
Le 02/09/2013 18:47, Brendan Eich a écrit :
Musical Notation mailto:musicdenotat...@gmail.com
September 2, 2013 7:43 AM
What about moving the standards development to WHATWG?
What about it?
You'll need to be more persuasive.
And I guess we're back to my original question: what derivative work
Hi,
What sort of derivative work do you want to do?
David
Le 30/08/2013 15:44, Musical Notation a écrit :
This document and possible translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
Le 23/08/2013 19:38, J B a écrit :
So the defacto response for large scale JS development will always be:
Use X?
Even if so, why would it be a big deal?
Just to clarify a point, I read interesting definitions of what weak,
strong, static and dynamic typing means [1]. Not sure how they are
Le 22/08/2013 02:23, Brendan Eich a écrit :
David Herman wrote:
To wit: I say leave it out.
This was TC39's consensus when I raised the option based on
SpiderMonkey (from ES4 days) allowing keywords as function names. (We
still carry that extension, BTW.)
Filed
Le 13/08/2013 06:07, David Herman a écrit :
On Aug 12, 2013, at 6:32 PM, David Bruant bruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash -- the web equivalent of this application has stopped
responding. You might as well ask
Le 13/08/2013 03:09, David Herman a écrit :
On Aug 12, 2013, at 5:43 PM, David Bruant bruan...@gmail.com wrote:
- I see *no* reasonable alternative to runaway microtask churn other than
slow-script dialog.
So did Dominic [1]. I suggested something else [2] and he found the idea
interesting
Hi,
Trying the move here the discussion happening at
https://bugzilla.mozilla.org/show_bug.cgi?id=686201 (recent discussion
starts comment 26)
Moving it here, because I believe it overlaps a lot with the ongoing
ES6/ES7 work bringing the event loop to ECMA262 (module loading,
Object.observe,
Le 08/08/2013 16:03, Domenic Denicola a écrit :
This is not a Trying to protect us from ourselves situation. This is a
browser
trying to protect users from any sort of abuse situation. For while loops,
they implemented the script takes too long dialog. For mistakenly infinitely
nested too short
Le 08/08/2013 16:43, Forbes Lindesay a écrit :
Also, on the point about draining the battery, using very short
timeouts is terrible for battery life but using `setImmediate` is
considerably better.
Why so?
David
___
es-discuss mailing list
Le 08/08/2013 16:03, Domenic Denicola a écrit :
To me the answer always seemed obvious: use the slow-script dialog.
What am I missing?
Maybe implementations could decide to break a microtask chain, but
instead of prompting a dialog, they just break it and call a callback
(later, in a different
Le 08/08/2013 17:00, Domenic Denicola a écrit :
Hmm, interesting!
I wonder if it could be event simpler than that, and after an arbitrary limit
(in time, not number of microtasks), just reschedule for the next event loop
turn's microtask phase. For promise applications there is no problem
Le 08/08/2013 22:04, Jason Orendorff a écrit :
On Thu, Aug 8, 2013 at 9:40 AM, David Bruant bruan...@gmail.com wrote:
Small delays between (micro)task sounds like a local maximum it's hard to
get away from unfortunately :-(
I think I was wrong here when it comes to microtasks.
Microtasks
Hi,
From http://qfox.nl/weblog/291
Apparently, f() = x was forbidden as of ES5.1 (was still available in
ES5 apparently), but a jQuery plugin is using it [1] (path not triggered
in non-IE browsers).
Not breaking the web, all that. It should probably be brought back.
Syntax isn't my cup of
Le 07/08/2013 15:44, Peter van der Zee a écrit :
To be honest, I was championing that parser writers should write
flexible and supportive parsers and put strict ocd parsing under a
flag/option. Especially in this case, where you need a parser that
should be able to parse content parsable by a
Le 05/08/2013 05:54, Brendan Eich a écrit :
David Bruant wrote:
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to
'Object(x) === x
Le 05/08/2013 17:08, Brendan Eich a écrit :
Michael Ficarra wrote:
specified that the global object's prototype chain must include
Object.prototype. I am sure there's plenty of code that depends on that.
Concern shared.
Yes, that's required.
Would it make sense to leave ECMAScript spec
Le 05/08/2013 20:11, Brendan Eich a écrit :
David Bruant wrote:
Would it make sense to leave ECMAScript spec intact (global's
[[Prototype]] is implementation-dependent),
No, we want interop across, e.g., Node.js and browsers, on such
features as whether toString resolves as a global
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to 'Object(x)
=== x'.
On a side note, I think your version of isObject is problematic
Le 03/08/2013 02:59, Brendan Eich a écrit :
David Bruant wrote:
Le 30/07/2013 00:12, Brendan Eich a écrit :
๏̯͡๏ Jasvir Nagra wrote:
Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of
http://wiki.ecmascript.org/doku.php?id
Le 03/08/2013 20:44, Brendan Eich a écrit :
David Bruant wrote:
I don't see the benefit of that against a file/function-wise directive.
Lexical means block in the modern Harmony era.
Excellent.
For both null and the new value types, I'm still unclear on why could
devs would choose
Le 02/08/2013 22:18, Brendan Eich a écrit :
Practically speaking, given dynamic-this-binding by default in JS,
it's too easy to access a foreign object with an important name
(private symbol in the hypothesis). It will happen. You will leak it.
It can then be used to attack you.
Sketched a
Le 01/08/2013 20:27, Mark S. Miller a écrit :
whatever DOM does quickly becomes a compat constraint on all future
decisions
(was the comma omitted on purpose? ;-) )
This also means that if there is a delta between the agreement and the
implementation, we'll have yet another de facto standard.
Le 01/08/2013 19:50, Brendan Eich a écrit :
Ian Hickson wrote:
Personally I'd like to drop document.domain entirely, but that's not
going
to fly any time soon.
Yeah, let's not waste time on things that won't fly.
Out of curiosity, are there recent data on setting document.domain?
It's been
2013/7/30 Allen Wirfs-Brock al...@wirfs-brock.com
On Jul 29, 2013, at 7:04 PM, David Bruant wrote:
Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit :
On Jul 29, 2013, at 5:11 PM, David Bruant wrote:
Nope. We would have had the same problems if we had kept [[Class]]. In
ES=5.1 [[Class
2013/7/30 Tom Van Cutsem tomvc...@gmail.com
tl;dr:
I would argue that Array.isArray should return true for proxies-for-arrays.
The other built-ins are less crucial and could stay the way they are.
What about WeakMaps? Maps? Sets?
How is the line drawn between crucial and less crucial? How is
Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit :
So far in ES=6 dealing with such private data slots is something that
could be treated in a relatively ad hoc manner within the ES spec. and
by implementations. But in ES7 we really want and need user definable
per instance private data. The
Le 30/07/2013 22:19, Allen Wirfs-Brock a écrit :
On Jul 30, 2013, at 12:40 PM, David Bruant wrote:
Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit :
...
But it still doesn't work the way you would like for direct call
invocation or for things like Array.isArray. The base issue for
either
Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit :
The legacy [[Class]] internal property conflated these two concepts. Sometimes
it was used for to ensure that a built-in method was operating upon an instance
that actually had the internal state or conformed to other implementation level
Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit :
On Jul 29, 2013, at 5:11 PM, David Bruant wrote:
Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit :
The legacy [[Class]] internal property conflated these two concepts. Sometimes
it was used for to ensure that a built-in method was operating
Hi,
Asked by Angus Croll [1]. Interestingly, people who answered giving code
didn't agree on a method or getter. Hence the need for a standard :-)
Array.prototype.first could work too.
David
[1] https://twitter.com/angustweets/status/359827047117373443
Le 28/07/2013 16:03, Alexandre Morgaut a écrit :
Using a method would be jQuery like:
- http://api.jquery.com/first/
- http://api.jquery.com/last/
but jQuery didn't had much choice has JS getter / setter are not supported by
older browsers
If it's added, let's build for the future and make a
Hi,
There seems to be a consensus on bringing in WeakRefs in the language. I
came around to the idea myself as some use cases seem to require it (as
in: some use cases can't be achieved even with a .dispose convention
like distributed acyclic garbage collection). However, I worry.
Recently,
Le 27/07/2013 18:22, K. Gadd a écrit :
Of course, I don't know how difficult it actually is to fix this.
Difficulty is obviously one major concern. If this was easy to fix, I
imagine it would have already been done; JS engine maintainers don't
keep easy-to-fix leaks for fun.
Also, apparently,
Le 27/07/2013 20:27, Brendan Eich a écrit :
Weak refs are necessary for observer patterns, as we've discussed ad
nauseum.
That's not the conclusion I took from these discussions. As I feel words
are important, the conclusions I took are:
WeakRefs are *necessary* for distributed acyclic garbage
Le 28/07/2013 01:11, Brendan Eich a écrit :
with confirmation from Rafael Weinstein:
https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html
This is exactly right.
let's quote a bit more from the same message:
Without WeakRefs, observation will require a dispose() step in order
Le 28/07/2013 03:15, Brendan Eich a écrit :
David Bruant wrote:
Each view and each model has some other object (maybe another view or
model or maybe some other object) that created it and bound it
respectively to a model or a view (or several). This creator/binder
(doesn't need to be unique
Le 25/07/2013 22:31, Erik Arvidsson a écrit :
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
I'm not sure I understand how this proposal lets TC39
2013/7/24 BelleveInvis infinte.c...@hotmail.com
I think that we can provide a more strict mode to deal with some
long-lasting defects. In more strict mode,
Why?
Who does this benefit?
You provide 5 rules. What ties them together? Why not other rules?
What would be the benefit of this new mode
2013/7/19 Jussi Kalliokoski jussi.kallioko...@gmail.com
myObject = {
someKey: 'someValue',
[MY_KEY_ID]: 'my value'
};
I believe this is already proposed at
http://wiki.ecmascript.org/doku.php?id=harmony%3Aobject_literals#object_literal_computed_property_keys
David
2013/7/17 Claus Reinke claus.rei...@talk21.com
For the specific case of forEach et al
What do you mean by et al? I don't believe .map, .reduce or .filter are
any interesting to use alongside generators.
And why not? Because yield is a statement, and because those
operations have not
[Freaking Gmail shortcuts! Sorry about that]
2013/7/17 David Bruant bruan...@gmail.com
Interestingly, myArray.filter(filterG).map(mapG) could be sort-of a lazy
value. Actual computation filterG and mapG happens only when generating
values from the
final generator.
This might enable
Le 16/07/2013 19:54, Claus Reinke a écrit :
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to use
.forEach instead of for..of.
for..of does what you need here with
2013/7/15 Brendan Eich bren...@mozilla.com
Andreas Rossberg wrote:
Yes, VMs do a lot to handle these cases well, and e.g. produce a flat
object representation for such examples. But like with all those
optimisations they are just optimistic, you still need to guard all
over the place,
Le 13/07/2013 10:21, Brian Di Palma a écrit :
I was just wondering
if the 'const' keyword would help give JS another small performance
boost.
Unlikely. Const can be almost statically inferred (no assignment to a
given variable). The almost refers to cases where eval happens. Worst
case, if
of talks on the topic at various conferences
already. Search on Youtube if the link I gave above isn't enough ;-)
David
On Sat, Jul 13, 2013 at 9:43 AM, David Bruant bruan...@gmail.com wrote:
Le 13/07/2013 10:21, Brian Di Palma a écrit :
I was just wondering
if the 'const' keyword would
Le 13/07/2013 20:55, Jeff Walden a écrit :
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
one more thing ... I believe this will impact arrow function too since is
basically bound callbacks all over the place (or at least this is how I believe
it will be transpiled)
Sadly, based on the
Hi,
I was wondering whether it was any useful to have the thisArg argument
in Array#find and Array#findIndex.
As of ES6, the language has Function.prototype.bind and arrow functions
and I would imagine these to be enough to cover any use case where
thisArg would be used.
I know that in the
Le 10/07/2013 14:48, Claude Pache a écrit :
Le 10 juil. 2013 à 11:26, David Bruant bruan...@gmail.com a écrit :
Hi,
I was wondering whether it was any useful to have the thisArg argument in
Array#find and Array#findIndex.
As of ES6, the language has Function.prototype.bind and arrow
Le 10/07/2013 16:53, Andrea Giammarchi a écrit :
Just a humble attempt to propose some addiction to the
`Object.prototype` I already know many will kill me for even trying to
...
**tl;dr** - everything proposed can be already tested through this
utility called
Le 10/07/2013 19:28, Brendan Eich a écrit :
David Bruant wrote:
I can't find it anymore, but I read a message from Mike Shaver (I
think it was him) saying that these methods have been standardized
after SpiderMonkey implementation without other form of rationale.
Who needs this particular
Le 10/07/2013 19:57, Jeremy Martin a écrit :
Events are already part of the interface of objects as people use them:
* in Node.js, events are documented at the same level than properties
and methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits
from EventTarget.
I
/EventedObjectsOnDirectProxies/EventedObject
On Wed, Jul 10, 2013 at 10:33 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 10/07/2013 16:53, Andrea Giammarchi a écrit :
Just a humble attempt to propose some addiction to the
`Object.prototype` I already
Le 10/07/2013 20:27, Anne van Kesteren a écrit :
On Wed, Jul 10, 2013 at 2:19 PM, David Bruant bruan...@gmail.com wrote:
This madness really has to stop. We need first class events (and I'm praying
for a way to retrofit them into the DOM if possible)
If you don't do the latter, I wonder how
Hi Eric,
Le 28/06/2013 19:42, Eric Elliott a écrit :
I know this has been batted around already.
Has it? :-p
I know everybody's totally stoked about class sugar in ES6. I just
wanted to register my protest. I made my arguments in this talk at Fluent:
Le 29/06/2013 00:14, Eric Elliott a écrit :
I'm however very interested if you could take a look at the current
proposal and tell if you can pin down how the current proposal makes
classes harmful for code maintainability.
Basically, my argument is that the whole paradigm of a class with a
Le 25/06/2013 02:36, Dmitry Soshnikov a écrit :
On Mon, Jun 24, 2013 at 5:00 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
On Mon, Jun 24, 2013 at 4:46 PM, Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de wrote:
Sorry for bringing this point
Le 20/06/2013 14:55, Forbes Lindesay a écrit :
I've been answering quite a few questions about promises on stack
overflow lately.
Do you have a link to a list to these questions (and/or your answers)
off-top your browser history by any chance?
One of the key things people seem to struggle
101 - 200 of 1196 matches
Mail list logo
