On Thu, Jan 17, 2013 at 10:02 AM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 18:00, Mark S. Miller a écrit :
However, after the Private Slots thread, I spent a sleepless night
chewing on getting rid of private symbols.
Happens to me so often :-)
I now think we should.
Going
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1] (is the
wiki down? I'm looking at google's cache),
I don't know, but seems
On Thu, Jan 17, 2013 at 1:50 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 17, 2013 at 1:13 PM, David Bruant bruan...@gmail.com wrote:
Le 17/01/2013 19:30, Mark S. Miller a écrit :
2) Until ES7 provides private
I may have missed something. In the harmony proposal on the wiki [1
On Wed, Jan 16, 2013 at 11:47 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
To compare the various scenarios, this is what (I believe) it looks like for
SES. In ES5, SES currently censors gOPN I believe, in order to implement the
equivalent of private keys and/or WeakMap.
SES includes
, Mark S. Miller wrote:
On Wed, Jan 16, 2013 at 11:47 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
To compare the various scenarios, this is what (I believe) it looks like
for
SES. In ES5, SES currently censors gOPN I believe, in order to implement
the
equivalent of private keys
On Tue, Jan 15, 2013 at 12:10 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
In defense of Kevin, I too would argue that private symbols add complexity
to the object model.
That doesn't mean I'm arguing in favor of removing private symbols, just
noting that we do pay a complexity price.
We
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
In theory, private symbols should have the same GC issues than WeakMap.
Consider:
var o = {}, o2 = {};
for(var i=0, i1000, i++){
let s = new Symbol(true /*private*/);
o[s]
On Tue, Jan 15, 2013 at 2:27 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eichbren...@mozilla.com wrote:
David Bruant wrote:
In theory, private symbols should have the same GC issues than WeakMap.
Consider:
var o
On Tue, Jan 15, 2013 at 3:03 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 1:58 PM, Brendan Eich wrote:
The GC cost is one problem, but the property access cost is another, and the
second allocation (wm for every obj) yet another. And as Dean just reminded,
My answer depends on a prior issue. Do we agree that in ES6,
RegExp.prototype is not itself a RegExp? Like the Date.prototype and
WeakMap.prototype we've already talked about, freezing it and
everything reachable from it must render it immutable, so that it
isn't a communications channel. SES
I think you now understand my proposal. By simple, I meant for
users, not implementors. I have no other disagreement with your
conclusion.
On Tue, Jan 15, 2013 at 5:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 3:46 PM, Mark S. Miller wrote:
On Tue, Jan 15, 2013
/2012/10/03/unique-pointers-arent-just-about-memory-management/
Le 14/01/2013 23:46, Mark S. Miller a écrit :
At
http://code.google.com/p/es-lab/downloads/detail?name=distr-erights-in-js.pdf
Paper for invited talk at ESOP2013 http://www.etaps.org/2013/esop13
Final already submitted, but comments
On Tue, Jan 15, 2013 at 6:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote:
Thanks. That's what I thought, but wanted to be sure.
In that case, I have no objections to any of these proposals, but I prefer
#4.
I really think whenever
deleted, at least for the record
here on es-discuss ;).
On Mon, Jan 14, 2013 at 2:57 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Mon, Jan 14, 2013 at 5:46 PM, Mark S. Miller erig...@google.com wrote:
At
http://code.google.com/p/es-lab/downloads/detail?name=distr-erights-in-js.pdf
Paper
On Mon, Jan 14, 2013 at 3:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
real-world contracts. For software contracts, we initially had a
footnote trying to explain the relationship between the smart
contracts we're talking about
On Mon, Jan 14, 2013 at 3:18 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Mon, Jan 14, 2013 at 6:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
real-world contracts. For software contracts, we initially had a
footnote trying
On Mon, Jan 14, 2013 at 3:31 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Mon, Jan 14, 2013 at 6:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
real
Since then, due to issues pointed out here on es-discuss, I withdrew
my consensus from this decision.
See also
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026971.html
where Andreas states the issue more clearly than I did.
On Sun, Jan 13, 2013 at 4:44 PM, Allen Wirfs-Brock
My reversal was posted at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026932.html.
Thanks there to Jussi Kalliokoski for also clearing up this issue.
On Sun, Jan 13, 2013 at 6:45 PM, Mark S. Miller erig...@google.com wrote:
Since then, due to issues pointed out here on es-discuss
On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in either it's an
On Sun, Dec 30, 2012 at 3:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
I agree. To me it comes down to cognitive load. A good way of measuring that
is whether one can state a simple rule. For Andreas’ approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eichbren...@mozilla.com wrote:
Who ever proposed that? It seems a misunderstanding. No one is saying
that,
e.g., destructuring formal parameters
On Sat, Dec 29, 2012 at 5:16 PM, Brendan Eich bren...@mozilla.com wrote:
I'm prepared to give up on the ban of duplicate formals when destructuring
parameters are present, if that will get rid of your objection to
micro-modes. I don't recall anything else like this case. We arrived at it
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a sufficiently minor player, that some cross-mobile-platform code
assumes mutable
On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
It does not even contain the word strict. IIRC (and I asked
about this at the last TC39 meeting and got verbal confirmation),
the idea of module {...} implying strict mode was latent, or
On Wed, Dec 26, 2012 at 3:03 PM, David Bruant bruan...@gmail.com wrote:
Le 26/12/2012 23:14, David Herman a écrit :
On Dec 24, 2012, at 2:34 PM, David Bruant bruan...@gmail.com wrote:
I've reading the loader API [1] and I was wondering if it was possible to
dynamically change the global. I
So does anyone know why? Own properties were the obvious choice, so
there must have been some reason to choose inherited accessors
instead.
On Thu, Dec 27, 2012 at 11:32 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
It's definitely been my experience that accessors, as found in IE and
Hi Brian, thanks for accumulating this data!
Between
* this data,
* Apple's decision as recorded at
https://bugs.webkit.org/show_bug.cgi?id=27226#c4,
* the new function syntax micro-modes,
* and the let issues already discussed,
I reiterate that we should stop trying to twist the language to
...@gmail.com wrote:
On Wednesday, December 26, 2012, Mark S. Miller wrote:
Hi Brian, thanks for accumulating this data!
Between
* this data,
* Apple's decision as recorded at
https://bugs.webkit.org/show_bug.cgi?id=27226#c4,
* the new function syntax micro-modes,
* and the let issues already
.
Dave
On Dec 26, 2012, at 2:03 PM, Mark S. Miller erig...@google.com wrote:
Hi Brian, thanks for accumulating this data!
Between
* this data,
* Apple's decision as recorded at
https://bugs.webkit.org/show_bug.cgi?id=27226#c4,
* the new function syntax micro-modes,
* and the let issues
On Wed, Dec 26, 2012 at 2:58 PM, David Herman dher...@mozilla.com wrote:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller erig...@google.com wrote:
Sorry, I'd completely forgotten about those earlier options. I am
arguing only the latter. Specifically Any ES6 features that don't fit
into non
we call it. I just hope we can stop sacrificing other
values for the sake of sloppy mode.
On Wed, Dec 26, 2012 at 6:35 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Dec 26, 2012 at 2:58 PM, David Herman dher...@mozilla.com wrote:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller erig
On Wed, Dec 26, 2012 at 4:59 PM, David Herman dher...@mozilla.com wrote:
On Dec 26, 2012, at 3:35 PM, Mark S. Miller erig...@google.com wrote:
I think you did coin 1JS. What do you mean by it? Does it bear on
the present issue or not?
I coined the just one JavaScript here:
https
On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
David Herman wrote:
On Dec 26, 2012, at 3:35 PM, Mark S. Millererig...@google.com wrote:
I think you did coin 1JS. What do you mean by it? Does it bear on
the present issue or not?
I coined the just one JavaScript
Chat below forwarded with Tom's permission. Conclusion is that, if we
go the getter/setter null-realm route, we should either do the minimal
null realm, with only getter/setter objects with null prototype (which
isn't observably a realm at all), or we should use SES as the null
realm. We both
[Reposted at David's request.]
-- Forwarded message --
From: Mark S. Miller erig...@google.com
Date: Tue, Dec 18, 2012 at 8:19 AM
Subject: Re: Function identity of non-configurable accessors
To: David Bruant bruan...@gmail.com
On Tue, Dec 18, 2012 at 8:08 AM, David Bruant bruan
On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The whole whole idea of such invariants was a late addition to ES5, and not
without some controversy. I don't think anyone believed that ES5 had a
complete set of invariants or even what that might be.
As part
On Tue, Dec 18, 2012 at 10:23 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If we are only talking about the Global Object, we can probably accommodate
almost anything by defining it as a special kind of exotic object.
AFAICT, we are only talking about the global object, in order to deal
inherited properties cannot be re-defined while sealed:false would be the
default?
Or maybe not ...
On Tue, Dec 18, 2012 at 9:31 AM, David Bruant bruan...@gmail.com wrote:
Hi,
Le 18/12/2012 18:08, Brendan Eich a écrit :
Mark S. Miller wrote:
That could work, but because of its complexity, I'm
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg rossb...@google.com wrote:
On 15 December 2012 22:52, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
So, to me, it sounds like that to continue down this path we should really
add new non-reflected properties attributes that are the real
On Mon, Dec 17, 2012 at 4:26 AM, Andreas Rossberg rossb...@google.com wrote:
On 17 December 2012 13:01, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg rossb...@google.com
wrote:
I see the following preferable solutions to deal with DOM features
EcmaScript koan:
NaN is NotANumber.
NaN is a number.
Object(NaN) is not a number.
Thus, Object(NaN) isn't NotANumber.
On Fri, Dec 14, 2012 at 9:22 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
That's my point. Normally
at 5:22 AM, Alex Russell slightly...@google.com
wrote:
+1. What Andreas said.
On Friday, December 14, 2012, Andreas Rossberg wrote:
On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com
wrote
On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
Le 14/12/2012 08:25, Brendan Eich a écrit :
window.location can be set by assignment to navigate to a new URL.
location is [Unforgeable, PutForward], so it should be reflected as a
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote:
I think this is the only viable solution.
Ok. What do you think of the idea of different handlers based on context?
[1]
[1] Last point of
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027092.html
Only if
Something I just posted in the public-script-coord thread bears repeating here:
A single invariant-violating object can be leveraged by direct proxies
to create any number of other objects that also violate invariants.
___
es-discuss mailing list
On Thu, Dec 13, 2012 at 7:05 PM, Brendan Eich bren...@secure.meer.net wrote:
Boris Zbarsky pointed out on public-script-coord that window.location and
window.document must be non-configurable _ab initio_, but perhaps this is
achievable with direct proxies?
This resolved into two suggestions,
On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban lu...@microsoft.com wrote:
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton
Subject: Number.isNaN
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would
it make sense
. Was this just
an oversight?
No. Object.is correctly reports that these are different.
I know `Object(NaN)` is totally edge case but it still has the
brand of BultinNumberWrapper and is NaN (boxed).
On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban lu...@microsoft.com wrote:
From: Mark S. Miller
On Wed, Dec 12, 2012 at 11:57 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
How would throwing early versus throwing late make any different to you?
Because 1) late is a waste, the result is undefined anyway, 2) the exception
thrown is a lie, the operation did not die on the property
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences
The current behavior is needed to enable to following repair:
--- some existing buggy library
class Foo ;
-
-- some importing and repairing library --
const BadFoo = Foo;
Foo = function .;
Foo.prototype = BadFoo.prototype;
BadFoo.prototype.constructor = Foo;
On Wed, Dec 5, 2012 at 8:05 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Dec 5, 2012 at 10:33 PM, Bill Frantz fra...@pwpconsult.com wrote:
On 12/5/12 at 1:50 AM, jussi.kallioko...@gmail.com (Jussi Kalliokoski)
wrote:
I personally think returning `this` in absence of any
On Wed, Dec 5, 2012 at 1:50 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
My 2 cents against the windmills...
I personally think returning `this` in absence of any meaningful value (and
chaining in general) is a bad pattern. Chaining leads to worse readability
(there's nothing
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has a bad reputation
because, in ES5, it is restrictive-only. There are
On Tue, Dec 4, 2012 at 1:04 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has
https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Dec 4, 2012 at 2:18 PM, Mark S. Miller erig...@google.com wrote:
https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ
I have received private email complaining about the biased language in
this poll, and that as a result it is merely a push poll
http
On Tue, Dec 4, 2012 at 3:57 PM, Brendan Eich bren...@mozilla.org wrote:
Benchmarks won't cut it if there's no organic developer pressure.
That is not the behavior I've observed in response to benchmarks,
either among JS implementors, or in the industry as a whole. Developer
pressure and actual
What eternal[1] invariant does this bypass?
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html
On Mon, Dec 3, 2012 at 3:33 AM, David Bruant bruan...@gmail.com wrote:
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target
Until ES7. If we try to solve all problems in ES6, it might not ship
earlier than ES7 anyway.
On Mon, Dec 3, 2012 at 4:38 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
the ES7-is-around-the-corner wager for two reasons.
The first reason
in ES7.
On Mon, Dec 3, 2012 at 6:28 PM, David Herman dher...@mozilla.com wrote:
On Dec 3, 2012, at 6:27 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed
On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
- after-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the after-wrapper may or may not get
to see the outcome of the operation, and may or may not change the final
outcome
On Fri, Nov 30, 2012 at 3:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
As I expressed in an earlier thread to es-discuss, Anne van Kesteren
is currently writing the URL spec, and as part of that he's designing
the URLQuery interface, which is essentially a MultiMap (a Map where
one key
to es-discuss and carry the discussion forward here.
Here is the first message with other to follow:
Begin forwarded message:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Date: November 18, 2012 1:26:14 PM PST
To: Tom Van Cutsem tomvc...@gmail.com, Mark S. Miller
erig...@google.com
Cc: Jason
[+es-discuss]
Speaking only for myself at this point -- I do not recall MultiMap
previously being suggested to the committee.
I think adding a MultiMap API to ES7 is a good idea. Neither Map nor
MultiMap should be a subclass of the other, since neither is an LSP
subtype of the other.
Since Map
On Tue, Nov 20, 2012 at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller erig...@google.com wrote:
[+es-discuss]
Speaking only for myself at this point -- I do not recall MultiMap
previously being suggested to the committee.
I think
How does Function('return this;') differ from (1,eval)('this') ? In both
cases, if Function/eval is the original one, it executes its arguments
non-strictly. This is unfortunate but all the alternatives were worse. SES
replaces both Function and eval with safe variants that (among other
things)
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith khs4...@gmail.com wrote:
I think you meant optimally colored bikeshed, but OK.
Ouch : )
Names are important. Especially when it comes to something as potentially
confusing as promises and futures.
I agree that names are important.
1) First
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller erig...@google.com wrote:
[...] In my code and in my Q specs
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency and
implementations
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/makeQ.js,
I have been
On Mon, Nov 12, 2012 at 2:12 PM, Irakli Gozalishvili rfo...@gmail.comwrote:
Lately I have being struggling with an implementation differences of host
(DOM) objects across the browsers.
So far only reliable way I could find to identify host objects is by a
following assertion:
. Question: is one-arg `then` + `fail` equally as
powerful as two-arg then? Proof?
Is the following a counter-example?
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller erig...@google.com wrote:
Hi David, thanks for your thoughtful post. I've always used the two-arg
form of .then[1], but your post
Hi David, thanks for your thoughtful post. I've always used the two-arg
form of .then[1], but your post makes a strong case for more often using
separate one-arg .then and .fail calls. I say only more often because the
two arg form can easily make distinctions that the one-arg forms cannot
On Fri, Nov 9, 2012 at 9:01 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com wrote:
Hi,
In this message, I'll be sharing some experience I've had with the Q
library. I have worked with it for about 7-8 months in a
On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer a...@rauschma.de wrote:
In theory, one can use prototype properties to provide default values for
instance properties. In practice, that is not often useful, because the
constructor normally creates all instance properties right away, assigning
On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg rossb...@google.comwrote:
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear, with roughly the semantics described by Andreas in Scala's API
[1]
and
On Mon, Nov 5, 2012 at 2:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
my point on namespaces was this one: everyone want's to use jQuery, then
underscore, then this or that ... then you need to be able to modify the
white list.
Thanks for the clarification. jQuery and much
On Mon, Nov 5, 2012 at 11:52 AM, Irakli Gozalishvili rfo...@gmail.comwrote:
Hi,
I keep running into cases where I would like to know if function is pure.
Although my interpretation of pure is not quite right but I don't know any
better name. By pure in this context I would refer to
I think closed strict function is adequate for these purposes. By
closed though, we need only mean except for the whitelisted globals,
using the whitelist at
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/whitelist.js
as updated for ES6.
On Mon, Nov 5, 2012 at
On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I see security problems all over ... you own your function, you can make
it pure or serializable ... you don't know your function, I believe
there's no way you want that unknown function to be executed in
is again a
security problem.
Making the whitelist modifiable would be fatal. I don't understand your
point.
On Mon, Nov 5, 2012 at 2:12 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I see security
modifiable
from anyone is again a security problem.
On Mon, Nov 5, 2012 at 2:12 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I see security problems all over ... you own your function, you can make
On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer a...@rauschma.de wrote:
(I am still sad we did not fix indexOf, lastIndexOf, and switch when we
arguably had the chance.)
Can you elaborate? We don’t have the chance, any more? Would anything
break (or did, in tests)?
I am not aware of
On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Also any reason contains should be provided for WeakMap? I not seeing why
it shouldn't be there too.
Yes!
The set of values actually contained by the WeakMap at any moment is
non-deterministic, depending on the
:53 PM, Mark S. Miller wrote:
On Fri, Nov 2, 2012 at 5:26 PM, Allen Wirfs-Brock
al...@wirfs-brock.commailto:
al...@wirfs-brock.com** wrote:
Also any reason contains should be provided for WeakMap? I not
seeing why it shouldn't be there too.
Yes!
The set of values actually
On Fri, Nov 2, 2012 at 8:19 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
I'll put up a proposal once electricity is back. I'll use the same
comparison as done in maps.
With it being the same comparison as maps (which use SameValue), +1. Note
that this makes contains/has inconsistent with
Fortunately, strings cannot contain -0.0 or NaN, so neither string.contains
nor string.has sets any relevant precedent. FWIW, neither does
string.indexOf nor string.lastIndexOf.
The only consistency issue is: should array.has agree with sense and all
other collections, or should it agree with
On Mon, Oct 29, 2012 at 9:35 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
Set.prototype.forEach
I thought it was agreed that the function passed to
Set.prototype.forEach would be called with 3 arguments, the value, the
value again and the context object. This is so that one can use the
Let's resolve this the same way as another open question left over from
ES5: What about the built-in functions? These are neither strict nor
non-strict, so ES5 is silent on whether they have these poisoned
properties. This oversight has caused us tremendous pain in SES, as seen by
searching for
That makes sense. As I said, I'd be happy with #2 for both. But please
let's decide both questions together.
On Fri, Oct 26, 2012 at 12:46 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 26, 2012, at 12:29 PM, Mark S. Miller wrote:
Let's resolve this the same way as another open
that these not be provided, so that it would
correspond correctly to your description: 'there is no caller nor
arguments property at all'.
On Fri, Oct 26, 2012 at 2:48 PM, David Bruant bruan...@gmail.com wrote:
Le 26/10/2012 21:29, Mark S. Miller a écrit :
(...)
#3 as is is unacceptable, because
On Fri, Oct 26, 2012 at 3:45 PM, David Bruant bruan...@gmail.com wrote:
Le 27/10/2012 00:23, Kevin Reid a écrit :
How about: there must be no *nonstandard non-configurable properties* of
standard objects.
Good. This agrees with
On Fri, Oct 26, 2012 at 5:45 PM, Waldemar Horwat walde...@google.comwrote:
How about: there must be no /nonstandard non-configurable properties/ of
standard objects.
Wouldn't that just preclude us from ever adding new standard
non-configurable properties to standard objects in the future?
S. Miller erig...@google.com wrote:
On Fri, Oct 26, 2012 at 5:45 PM, Waldemar Horwat walde...@google.comwrote:
How about: there must be no /nonstandard non-configurable properties/ of
standard objects.
Wouldn't that just preclude us from ever adding new standard
non-configurable
On Mon, Oct 22, 2012 at 5:27 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Monday, October 22, 2012 at 1:04 AM, Domenic Denicola wrote:
Thanks for your help Rick! I've corrected a few, but wasn't sure about
some others. Let me know if I'm missing something in the following:
From: Rick
On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz wyc...@gmail.com wrote:
On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller erig...@google.comwrote:
Getting the comments with a getter seems fine. Appending only the list of
comments with a setter is bad, as it does not resemble storage semantics
Getting the comments with a getter seems fine. Appending only the list of
comments with a setter is bad, as it does not resemble storage semantics. I
would expect well written setters to at least be idempotent, and well
written getters to be side effect free.
On Tue, Oct 16, 2012 at 2:36 PM, Tab
On Mon, Oct 15, 2012 at 9:17 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Oct 12, 2012, at 2:16 PM, David Herman wrote:
On Oct 12, 2012, at 12:14 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Fri, Oct 12, 2012 at 11:16 AM, David Bruant bruan...@gmail.com
wrote:
701 - 800 of 1628 matches
Mail list logo
