from both iterable and original WeakSet.
>
ok, I don't have an opinion on this idea
David
>
>
>
> On 9 Feb 2018 4:01 pm, "David Bruant" <bruan...@gmail.com> wrote:
>
>> Hi,
>>
>> My understanding is that cloning a WeakSet into a Set would r
Hi,
My understanding is that cloning a WeakSet into a Set would remove all its
properties related to security and garbage collection.
The properties related to security and garbage collection of WeakSet are
based on the fact that its elements are not enumerable by someone who would
only be
Le 06/02/2017 à 17:59, Ryan Birmingham a écrit :
Hello all,
I frequently find myself desiring a short array or generator
comprehension syntax. I'm aware that there are functional ways around
use of comprehension syntax, but I personally (at least) love the
syntax in the ES reference
Hi Kris,
Le 17/06/2016 06:44, Kris Siegel a écrit :
I didn't see this in the archives but I was curious if any
consideration has been given for standardizing on features more
commonly found in most other language's standard library.
For example reading and writing to sockets in JavaScript
Le 01/12/2015 20:20, Michał Wadas a écrit :
As we all know, JavaScript as language lacks builtin randomness
related utilities.
All we have is Math.random() and environment provided RNG -
window.crypto in browser and crypto module in NodeJS.
Sadly, these APIs have serious disadvantages for
Hi,
Le 03/11/2015 12:26, Alexander Jones a écrit :
In my opinion, the fundamental record type we build our JS on should
be getting dumber, not smarter. It feels inappropriate to be piling
more difficult-to-reason-about mechanismson top before reeling in
exotic host objects.
JS objects were
Lots of the changes were long awaited. ES2015 is an important milestone.
More important even is the momentum and recent changes to the way people
can contribute to the standard.
Thank you to everyone involved in making all of this happen!
David
Le 17/06/2015 17:46, Allen Wirfs-Brock a écrit
Hi,
Le 23/02/2015 10:10, Michał Wadas a écrit :
Cloning objects is long requested feature.
clone object javascript yields 1 480 000 results in Google.
I'd like to share this as an answer
http://facebook.github.io/immutable-js/#the-case-for-immutability
If an object is immutable, it can be
Hi,
I was trying to find the module Loader in the latest draft, but found
out that it's been removed from it [1][2].
YK: The loader pipeline will be done in a living spec (a la HTML5)
so that Node and the browser can collaborate on shared needs.
I haven't been able to find this new document
Hi,
Half a million times the following meta-exchange happened on es-discuss:
- if an attacker modifies Object.prototype, then you're doomed in all
sorts of ways
- Don't let anyone modify it. Just do Object.freeze(Object.prototype)!
I've done it on client-side projects with reasonable success.
Le 13/01/2015 13:21, Anne van Kesteren a écrit :
A big challenge with self-hosting is memory consumption. A JavaScript
implementation is tied to a realm and therefore each realm will have
its own implementation. Contrast this with a C++ implementation of the
same feature that can be shared
Le 20/12/2014 13:47, Gary Guo a écrit :
bindParameter function is not very hard to implement:
```
Function.prototype.bindParameter=function(idx, val){
var func=this;
return function(){
var arg=Array.prototype.slice.call(arguments);
arg[idx]=val;
func.apply(this,
Le 04/12/2014 09:55, Andreas Rossberg a écrit :
On 4 December 2014 at 00:54, David Bruant bruan...@gmail.com wrote:
The way I see it, data structures are a tool to efficiently query data. They
don't *have* to be arbitrarily mutable anytime for this purpose.
It's a point of view problem
Le 03/12/2014 16:26, Jason Orendorff a écrit :
On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg rossb...@google.com wrote:
(Back to the actual topic of this thread, you still owe me a reply
regarding why .clear is bad for security. ;) )
I'd like to hear this too, just for education value.
Le 03/12/2014 19:10, Jason Orendorff a écrit :
On Wed, Dec 3, 2014 at 9:04 AM, David Bruantbruan...@gmail.com wrote:
A script which builds a weakmap may legitimately later assume the weakmap is
filled. However, passing the weakmap to a mixed-trusted (malicious or buggy)
script may result in
Hi,
I feel like I've been in an equivalent discussion some time ago, so
taking the liberty to answer.
Le 02/12/2014 13:59, Andreas Rossberg a écrit :
On 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Le 02/12/2014 14:24, David Bruant a écrit :
Hi,
I feel like I've been in an equivalent discussion some time ago
The topic felt familiar :-p
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0322.html
David
___
es-discuss mailing
Le 23/11/2014 07:41, Axel Rauschmayer a écrit :
I’d expect the following code to log `GET bla`, but it currently
doesn’t in Firefox. That’s because the Firefox implementation of
proxies isn’t finished yet, right?
Yes. That would be https://bugzilla.mozilla.org/show_bug.cgi?id=914314 I
think.
Le 13/11/2014 17:29, Boris Zbarsky a écrit :
On 11/13/14, 6:44 AM, Andreas Rossberg wrote:
Well, the actual diabolic beast and universal foot gun in this example
is setPrototypeOf. ;)
Note that there is at least some discussion within Mozilla about
trying to make the prototype of
The best defense is Object.freeze(Object.prototype);
No application worth considering needs to arbitrarily modify
Object.prototype at an arbitrary point in time (or someone should bring
a use case for discussion). It usually shouldn't and even if it does, it
should do it at startup and freeze
Le 12/11/2014 17:23, Tom Van Cutsem a écrit :
I agree with your sentiment. I have previously advocated that
Array.isArray should be transparent for proxies. My harmony-reflect
shim explicitly differs from the spec on this point because people
using the shim spontaneously reported this as the
Le 09/11/2014 15:07, Jussi Kalliokoski a écrit :
I figured I'd throw an idea out there, now that immutable data is
starting to gain mainstream attention with JS and cowpaths are being
paved. I've recently been playing around with the idea of introducing
immutable collections as value types (as
Le 29/09/2014 23:08, Anne van Kesteren a écrit :
On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
I certainly wouldn't object to the ES spec's event loop algorithms being
turned inside out (search for RunCode on the esdiscuss thread above for
an e-mail where I propose this) but
Le 02/09/2014 20:07, Daurnimator a écrit :
So, I'd like to see some sort of trap that is fired when a Proxy is
collected.
To prevent over specifying how Javascript garbage collectors should
operate,
I propose that the trap *may* only be called at some *undefined* point
after the object is not
Yes. Needed it recently.
Ended up doing .then(f).catch(f) which can be survived but feels stupid.
David
Le 18/08/2014 21:20, Domenic Denicola a écrit :
Here is the current design for Promise.prototype.finally. I agree it is a
useful feature.
Le 31/07/2014 09:25, Maxime Warnier a écrit :
Hi everybody,
I was reading the doc for the new Set method and something suprised me :
Why Set uses the size method instead of the length property ?
IIRC and with my own words length refers more to something that can be
measured contiguously (like
Le 27/07/2014 13:35, Peter van der Zee a écrit :
On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller erig...@google.com wrote:
Hi Peter, what is the security issue you are concerned about?
Unless `Reflect` is completely sealed out of the box, you can never
know whether properties on it are the
Hi,
Le 25/07/2014 20:52, Michaël Rouges a écrit :
Hi all,
There is any plan around un functionnality like the use keyword, in PHP.
Why something like that? Because, in JS, there is no way to inject
some variables, without touch the this object known in a function.
Can you give an example of
Hi,
I'm not quite sure what this is all about, so forking in hope for
clarifications.
I'm sorry to send a message that will probably be read as noise by a lot
of people, but I'm also tired of some of these pointless and
unconstructive, if not destructive, fights among people (in here, on
Le 12/06/2014 16:43, Domenic Denicola a écrit :
Also, David: modules are not named; you cannot import them. Check
out
https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
Thanks, that's the context I was missing.
I'm uncomfortable with the async part of the proposal as
Le 11/06/2014 18:08, Ben Newman a écrit :
https://gist.github.com/annevk/3db3fbda2b95e5ae9427
AWB: Should we try to replace WebIDL? (fourth bullet point from the
gist above)
For what purpose? Replacing WebIDL isn't an end in itself.
Who would be the target of this replacement? Spec writers
Le 11/06/2014 18:21, Ben Newman a écrit :
## 7.1 script type=module status update (from DH)
DH: Would really rather have moduleimport { foo } from bar;
.../module, which is like script but async, strict mode, has its
own top-level scope, and can import declaratively (using ES6 module
import
Hi Maxime,
Good to see you here :-)
This topic has been discussed recently on Twitter. See
https://twitter.com/jeremyckahn/status/474259042005553154
I'm like Rick's answer in particular
https://twitter.com/rwaldron/status/475017360085364736
as I believe a large share of cloning is just about
Le 06/06/2014 01:08, Rick Waldron a écrit :
On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas
standa...@nczconsulting.com mailto:standa...@nczconsulting.com wrote:
* `Object.deepPreventExtensions()`, `Object.deepSeal()`,
`Object.deepFreeze()` - deep versions of
Le 06/06/2014 15:57, Mark S. Miller a écrit :
By contrast, a Map's state is more like the private instance variable
state of a closure or a post-ES6 class.
The capabilities to arbitrarily modify Maps (set/delete on all keys,
with any values) will be expected by any ES6-compliant code to be
using forEach/map/filter/reduce, I haven't had
an off-by-one error on arrays. Highly recommanded! (I think I've heard
Crockford making the same recommandation in a recent talk, but I cannot
find the link)
David
On Fri, Jun 6, 2014 at 7:37 AM, David Bruant bruan...@gmail.com
mailto:bruan
Le 06/06/2014 18:16, Nicholas C. Zakas a écrit :
On 6/6/2014 8:38 AM, Mark S. Miller wrote:
But the concern Nicholas raises doesn't seem to have this
property. Reading a property that doesn't exist doesn't carry a
security risk, does it? Object.preventUndeclaredGet doesn't
Le 14/05/2014 19:13, Axel Rauschmayer a écrit :
What is the best “bytecode isn’t everything” article that exists? The
“the web needs bytecode” meme comes up incredibly often, I’d like to
have something good to point to, as an answer.
This one looks good:
Le 09/05/2014 08:50, Tom Van Cutsem a écrit :
Rick,
It's true that allowing user-invented custom attributes will not break
any important existing invariants (except perhaps that all existing
descriptors can be assumed not to have any own properties besides the
standard attributes. Existing
Le 26/03/2014 19:24, Jason Orendorff a écrit :
use strict;
function Pony() {}
Object.freeze(Object.prototype);
Pony.prototype.toString = function () { return Pony; };
The last line here throws a TypeError in ES5 and ES6.* Can we change
it? To me, it stands to reason that
Le 23/03/2014 19:24, Brendan Eich a écrit :
Marcus Stade wrote:
This is assuming that the `current` or `prev` property is indeed
implemented by the engine and not user land, as that indeed both
carries implementation cost and the risk out running out of sync. Is
there any way other than
Le 16/03/2014 00:45, Rick Waldron a écrit :
On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff
jason.orendo...@gmail.com mailto:jason.orendo...@gmail.com wrote:
On Sat, Mar 15, 2014 at 5:19 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Even if error prone
Le 15/03/2014 01:32, Brandon Benvie a écrit :
On 3/14/2014 5:16 PM, Mark Volkmann wrote:
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
in the
sense that the risk outweighs the benefits. Iterable-by-default objects
is a nice battery included feature.
David
--scott
On Mar 15, 2014 7:42 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 15/03/2014 01:32, Brandon Benvie a écrit :
On 3/14/2014 5
Le 10/03/2014 08:02, Tom Van Cutsem a écrit :
Using Firefox's built-in direct proxies implementation I get a
TypeError. I'll investigate further and file a bug.
You already did https://bugzilla.mozilla.org/show_bug.cgi?id=601379 ;-)
David
___
Le 05/03/2014 09:24, Eric Elliott a écrit :
What ever happened to Array.prototype.contains? There's an old
strawman for Array.prototype.has (
http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has )
that references this thread: (
Le 03/03/2014 10:11, Andy Wingo a écrit :
On Sun 02 Mar 2014 04:18, Domenic Denicola dome...@domenicdenicola.com writes:
You can just do `if (Symbol.iterator in potentialIterable)`.
Of course, this can introduce time-of-check-to-time-of-use bugs.
Actually calling @@iterator on the iterable is
Le 20/02/2014 06:39, Brendan Eich a écrit :
Bradley Meck wrote:
If I am reading the spec right (and I may not be), only the generator
should fail? The first call to gen().next(value) must have value be
undefined, and the others do not check.
I thought we agreed at the January 28 meeting to
Le 20/02/2014 15:03, Andy Wingo a écrit :
Hi,
This isn't really an es-discuss topic, as it is about performance of
implementations rather than the language itself.
Stating my own opinion only on behalf of myself: I think this thread
appropriate for es-discuss. How developers use the language
Le 17/02/2014 22:55, Benjamin (Inglor) Gruenbaum a écrit :
My issue here is that I want to index on complex values. I was under
the impression ES6 maps solve amongst others the problem that with
objects - keys are only strings.
With maps, all native types (string, number, boolean, undefined,
Hi,
In the latest draft, I see String.prototype.contains, but no
Array.prototype.contains
I see something about a no-brainer here
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019108.html
I haven't found a bug on bugs.ecmascript or a mention in the meeting notes.
Or was it
Le 07/02/2014 22:05, Brendan Eich a écrit :
Kevin Smith wrote:
- A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before any
spec language is authored. Spec-language is a poor medium for
communicating both design intent
Le 27/01/2014 06:45, Brendan Eich a écrit :
Kevin Smith wrote:
Is a new attribute necessary? What about using @type?
Old browsers will ignore unknown types, losing the two-way
fallback option.
Two-way fallback? Why is that important? Since modules are
implicitly strict,
Le 27/01/2014 19:41, David Herman a écrit :
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app
Le 24/01/2014 18:26, John Lenz a écrit :
REPL is a dilemma: if you parse as module, then obtaining the last
expression value is not simple. if you parse as a script, then
common cut/paste fails on export/import statements.
My basic question remains. As a tool owner how do I know
Le 20/01/2014 23:16, Kevin Reid a écrit :
SES needs to visit every 'primordial' / 'singleton' object to ensure
they're made immutable and harmless. (Other 'meta' code might also
benefit though I don't know of any examples offhand.)
This job is easier if all such objects are reachable via
Le 20/01/2014 18:39, Brendan Eich a écrit :
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it
via:
(function *() {}).constructor
Do we even need (function *() {}).constructor !==
Hi,
Playing with the test cases of the regenerator project [1], I came
across a case and was wondering what the intention of the spec is given
that Firefox and Chrome recent implementations diverge.
Apologies for not reading all the previous discussions on this edge case.
Test case:
js
Hi Ben,
Sorry for the very late response.
This is quite an interesting work, thanks for sharing!
I'm particularly interested in your test suite [1] which is impressive.
This is making me realize that generators are fully compilable
(efficiently from what I can see) into ES5 and makes me wonder
Le 11/01/2014 18:03, Brendan Eich a écrit :
Axel Rauschmayer wrote:
I know this runs counter the conventional wisdom for specs, but I
find design rationales incredibly important for making sense of
what’s going on: The answers and discussions on this mailing list
were essential in helping me
Hi,
I'm starting a documentation on the iterator protocol and wanted to ask
a few things just to be 100% sure, because some things may leave room to
ambiguities.
## Just for confirmation
First, on the relevant TC39 meeting notes [1]. It is suggested that
Without Brendan, a champion of
Hi Maciej,
Le 08/01/2014 09:59, Maciej Jaros a écrit :
To my understanding private name objects
Note that now their name is symbol and not private name anymore.
are supposed to make private properties and functions available for
new classes syntax in ECMAScript 6 standard.
A private keyword
Hi,
I've been playing with Sets recently and believe that the following
additions would make them more useful by default:
* Set.prototype.map
* Set.prototype.filter
* Set.prototype.toJSON = function(){
return [...this];
};
The 2 first are to easily create sets from existing sets very much
for some static methods too like Set.union
and Set.intersection. These are annoying with arrays (while keeping
uniqueness of elements)
David
On Dec 31, 2013, at 11:36 AM, David Bruant bruan...@gmail.com wrote:
Hi,
I've been playing with Sets recently and believe that the following
Le 31/12/2013 20:52, Calvin Metcalf a écrit :
I had the same idea a couple weeks ago and turned it into a library
https://github.com/calvinmetcalf/set.up if anyone finds it useful.
hmm... It is useful, but not future-proof. If methods with these names
ever get standardized, your code will
Le 29/12/2013 14:42, Brendan Eich a écrit :
David Bruant wrote:
Le 29/12/2013 01:48, Brendan Eich a écrit :
David Bruant wrote:
it's somewhat ironic that Array carries 'from' given it's the only
class that doesn't need it per case study for 3) above :-)
But Array is the return type.
It's
Le 27/12/2013 19:10, Claude Pache a écrit :
There is still the issue of potential libraries that produce
arraylikes that don't inherit from a built-in arraylike prototype:
those won't benefit from your polyfill without changing their
inheritance strategy.
I don't understand the expression
Le 28/12/2013 15:25, Brendan Eich a écrit :
This seems overcomplicated. Isn't the likelier code something like
Array.from || (Array.from = function(b) { var a=[]; for (var i=0;
ib.length; i++) a.push(b[i]); return a; });
Isn't the whole point to impute arraylikeness to the parameter?
In
Le 29/12/2013 00:11, Rick Waldron a écrit :
On Sat, Dec 28, 2013 at 5:44 PM, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
I believe that Array.from's only purpose is to provide guidance
for polyfills for people to use in ES3/ES5 code; nobody
Le 29/12/2013 01:48, Brendan Eich a écrit :
David Bruant wrote:
it's somewhat ironic that Array carries 'from' given it's the only
class that doesn't need it per case study for 3) above :-)
But Array is the return type.
It's always the return type of Array.from(x), but not the return type
Le 26/12/2013 05:00, Rick Waldron a écrit :
On Wed, Dec 25, 2013 at 7:33 PM, David Bruant
For the rationale, the wiki states [1]:
There are many array-like objects in JS (arguments objects, DOM
NodeLists, arrays from separate windows, typed arrays) and no
simple way to convert
Le 26/12/2013 10:58, David Bruant a écrit :
Le 26/12/2013 05:00, Rick Waldron a écrit :
On Wed, Dec 25, 2013 at 7:33 PM, David Bruant
For the rationale, the wiki states [1]:
There are many array-like objects in JS (arguments objects, DOM
NodeLists, arrays from separate windows
Hi,
I was reading the current spec for Array.from and it felt too
complicated to me. Currently, at a high-level it reads like:
1) if the argument is iterable (@@iterable symbol), create a fresh array
made of the values iterated on with the iterator
2) (step9) if the object is array-like, len =
Le 17/12/2013 22:52, Alex Kocharin a écrit :
I believe ecmascript isn't versionless yet like html is, and that
number means something.
As far as I'm concerned, ECMAScript is versionless. As versionless as
HTML. Implementation aren't monolithically moving from one standard
version to the
Le 17/12/2013 10:19, Shijun He a écrit :
There are some methods using reserved word delete, such as
Map.prototype.delete, Set.prototype.delete... Though it is allowed
since ES5, I think we'd better avoid it because it cause es6 shim
solution fail on legacy browsers such as IE8.
Note that there
Le 16/12/2013 22:42, Anne van Kesteren a écrit :
If you're unclear on the name, just make it clear in the specification
that the name is not stable and that therefore it cannot ship yet (you
could implement it and ship it in nightlies and such of course).
Or don't put it in the spec at all?
Le 16/12/2013 22:51, Oliver Hunt a écrit :
(I know Anne knows this argument, but i’m emailing this logic for people who
aren’t aware of it)
The reason for prefixing APIs is to allow a feature to be shipped and used by
developers before the final api semantics are settled on. In the event the
Le 28/11/2013 09:59, Brandon Andrews a écrit :
Lately I've been writing very processor heavy Javascript. I feel like it could
benefit a lot from having a syntax feature for removing debug statements.
Obviously JS is interpreted and not compiled, so I'm not sure if this sounds
completely
Le 27/11/2013 19:14, Rick Waldron a écrit :
# Nov 19 Meeting Notes
## 4.4 Finalizing the Proxy API for ES6
(Presented by Tom Van Cutsem)
(...)
DS: What is typeof and instanceof
AWB/BE: object
BE: Capital P
AWB: Ca???
DS: Whatever Proxy creates?
BE: That depends on what is created.
DS:
Le 13/11/2013 06:15, Boris Zbarsky a écrit :
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error
Le 13/11/2013 08:11, Boris Zbarsky a écrit :
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem like the wrong
tool to solve this problem.
I think I agree on that.
Ideally, the ECMAScript error sink would handled both uncaught thrown
errors
Le 12/11/2013 10:18, Pierre Frisch a écrit :
Could I present another example where WeakRef are required.
I am writing an object management layer similar to what exist in other language
and systems. One of the requirement is uniquing so that each object exist only
once in memory. Let say I
Le 12/11/2013 18:30, Axel Rauschmayer a écrit :
This is relevant, too:
http://esdiscuss.org/topic/function-declarations-with-lexical-this
I'd still argue that generator arrow functions make more sense than
generator function declarations.
I don't have a strong opinion in this debate, but I've
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled. I have been looking forward for WeakRef as
one of the avenues available to mitigate this problem. A post-mortem
finalizer would be able to surface an
Le 10/11/2013 19:12, Allen Wirfs-Brock a écrit :
One of the the few remaining uses of a function's 'arguments' binding
is to determine the actual number of passed arguments. This is
necessary in some overloading scenarios where a function has different
behavior when an argument is completely
Le 10/11/2013 22:19, Brendan Eich a écrit :
On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Not sure why this is so needed though.
Allen's posts make the case: webidl and varargs-style functions. Not all legacy.
WebIDL creates spec, not code. The language
Le 10/11/2013 22:30, K. Gadd a écrit :
JSIL and embind both need arguments.length for efficient method call
dispatch when dealing with overloaded functions. Is it your intent
that all such scenarios must now pay the cost of creating an array (to
hold the rest arguments) and then destructuring
Le 10/11/2013 22:42, Brendan Eich a écrit :
On Nov 10, 2013, at 9:24 PM, David Bruant bruan...@gmail.com wrote:
WebIDL creates spec, not code. The language syntax doesn't need to evolve for
that.
Wrong, webidl and jsidl (and jsil and embind) are both interface and a bit of
implementation
Le 10/11/2013 23:34, Brendan Eich a écrit :
Dmitry Soshnikov wrote:
Moreover, for this particular `splice` example, I don't think the
`(start, deleteCount, ...rest)` is the best signature (not to say,
incorrect signature). As again was mentioned, a var-args function
seems should just use the
Le 08/11/2013 17:09, Jason Orendorff a écrit :
(As a bonus, the weirdness will happen in one implementation and not
another, and you and your users will blame the implementation. So
there will be pressure on implementers to reduce the nondeterminism by
doing GC more frequently—which trades off
Le 08/11/2013 20:35, Mark S. Miller a écrit :
Please try -- such experiments are interesting.
I am :-)
But even if this experiment is successful, I hope and expect that
we'll have weakrefs and post-mortem finalization in ES7. They are
needed for many other things, such as distributed acyclic
Le 07/11/2013 22:46, K. Gadd a écrit :
That's the sort of obstacle that factors into a developer's choice of
language and toolset. I've seen this particular concern with ES crop
up in the past on real projects, and I've seen firsthand how difficult
it is to avoid uncollectable cycles in a
Le 02/11/2013 03:13, Allen Wirfs-Brock a écrit :
On Nov 1, 2013, at 6:05 PM, David Bruant wrote:
I'm not sure about proxy returning Proxy as tag name. Is that a good idea?
Brand feels like something that could safely transparently cross proxies.
There is a note on in the ES6 draft
Le 02/11/2013 01:08, Brandon Benvie a écrit :
On 11/1/2013 4:59 PM, Brandon Benvie wrote:
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of Arguments, Array, Boolean, Date, Error,
Function, Number, RegExp, or String and SameValue(tag,
Le 31/10/2013 16:38, Anne van Kesteren a écrit :
This keeps coming up. Last instance:
http://mxr.mozilla.org/mozilla-central/source/dom/base/ObjectWrapper.jsm#16
We have it for Array using Array.isArray().
Array.isArray is not at all equivalent to instanceof. Not even related.
Le 26/10/2013 15:44, Michaël Rouges a écrit :
Bonjour à tous,
Bonjour,
`Knowing that every function is an object, I am surprised that the
Object.create() method doesn't really allow cloning function.
I don't follow the logic of this sentence.
In any case, the purpose of Object.create is to
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6
standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the
Le 14/10/2013 23:25, Brendan Eich a écrit :
Jorge Chamorro wrote:
The only work around for that is making as few requests as possible.
+∞, +§, and beyond.
This is deeply true, and a hot topic with browser/network-stack
engineers right now.
It ought to be with software engineers as well and
Le 14/10/2013 23:20, Jorge Chamorro a écrit :
On 14/10/2013, at 22:11, David Bruant wrote:
You already can with inlining, can't you?
Yes and no:
-It's much more complicated than pre zipping a bunch of files and adding a ref
attribute.
-It requires additional logic at the server side
Le 14/10/2013 15:16, Anne van Kesteren a écrit :
The idea is to use a somewhat more unique separator, e.g. $sub/. Old
browsers would simply fetch the URL from the server and if the server
is written with legacy in mind would serve up the file from there. New
browsers would realize it's a
1 - 100 of 1196 matches
Mail list logo
