The argument against introducing non-determinism (or GC-dependent determinism)
from maybe a month ago seems much stronger than that of covert channels. A
claim of a reasonable implementation of a production language to be free of
covert channel is rather suspect. E.g., preventing covert
2010/8/14 Mark S. Miller erig...@google.com:
On Sat, Aug 14, 2010 at 1:01 PM, Ash Berlin ash...@firemirror.com wrote:
On 14 Aug 2010, at 07:22, Erik Arvidsson wrote:
I have a few questions regarding the WeakMap API.
1. Why isn't there a way to check for presence of a key (using
On Sep 2, 2010, at 12:29 AM, Brendan Eich wrote:
On Sep 2, 2010, at 12:08 AM, Leo Meyerovich wrote:
That said, going back to the beginning: deterministic GC-independent
semantics are a Good Thing. Whether this matters seems to be a crucial
discussion. Is there a concern for basic
2010/9/2 Leo Meyerovich lmeye...@gmail.com:
On Sep 2, 2010, at 12:29 AM, Brendan Eich wrote:
On Sep 2, 2010, at 12:08 AM, Leo Meyerovich wrote:
That said, going back to the beginning: deterministic GC-independent
semantics are a Good Thing. Whether this matters seems to be a crucial
On 02.09.2010 2:44, Mike Samuel wrote:
2010/9/1 Irakli Gozalishvilirfo...@gmail.com:
I have not seen the post before, but it perfectly expresses my concerns.
I still do think though that if breaking backwards compatibility is on the
table solving syntactic noise issue is not such a bad idea
I would strongly oppose any way to trigger a full garbage collection
from JavaScript. Experience from the Java world shows that it is
inevitably abused with very serious performance consequences.
Red herring, though JVM deployments seem like good examples of systems using
advanced
I would like to agree that .keys would expose some of the internal workings
of the GC. This is true, but the solution to that could be to remove .keys()
off the individual WeakMap for secure operations, however in some situations
where a WeakMap is sandboxed within a closure or such, having .keys
On Thu, Sep 2, 2010 at 8:05 AM, Bradley Meck bradley.m...@gmail.com wrote:
I would like to agree that .keys would expose some of the internal workings
of the GC. This is true, but the solution to that could be to remove .keys()
off the individual WeakMap for secure operations,
Remove off of
On Thu, Sep 2, 2010 at 12:46 AM, Erik Corry erik.co...@gmail.com wrote:
And this is as it should be. As it stands the weak map can be used as
an object with private members. The object key acts as a capability
that controls whether or not you have access to the private member.
If I were to
That page currently has TBD semantics. Two questions:
Syntax aside, is the observable semantics of Names different from
http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields?
How? If the only semantic difference is (not normally observable) less
aggressive GC
On Thu, Sep 2, 2010 at 9:47 AM, Mark S. Miller erig...@google.com wrote:
That page currently has TBD semantics. Two questions:
Syntax aside, is the observable semantics of Names different from
http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields?
How? If the only
That page currently has TBD semantics.
Yeah, that's part of the work that needs to be done. Intuitively, it's a simple
idea: ToName essentially generalizes the current semantics of property lookup;
instead of trying to convert the property to a string, you try to convert it to
a
2010/9/2 Mike Shaver mike.sha...@gmail.com:
On Thu, Sep 2, 2010 at 12:46 AM, Erik Corry erik.co...@gmail.com wrote:
And this is as it should be. As it stands the weak map can be used as
an object with private members. The object key acts as a capability
that controls whether or not you have
On Thu, Sep 2, 2010 at 11:32 AM, Erik Corry erik.co...@gmail.com wrote:
Surely that is the case with WeakMap? At least unless you lost the
key and don't have any other references to the value. In which case
you can't reach the value any more, so why would you care whether it
is kept alive?
On Sep 2, 2010, at 9:14 AM, Mark S. Miller wrote:
(Btw, *please* don't call non-strict mode normal.)
To emphasize Mark's point, ES-Harmony is based on strict mode. It's the new
normal :-P.
/be___
es-discuss mailing list
es-discuss@mozilla.org
15 matches
Mail list logo
