When executing this code:
(function () {
eval(var x=delete(x))
})()
I think the assertion in the ECMAScript description of the declarative
environment record's SetMutableBinding algorithm, 10.2.1.1.3 step 2, fails.
* On entry to the function, we create a lexical environment
On Mar 21, 2011, at 12:50 AM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote:
The revision would address all my concerns — thanks. I'm all for
distinguishing the static case from the dynamic case, as long as we can
maintain the separation between public names
I think you've rediscovered the bug mentioned in the list thread titled Assigning
to eval-introduced local bindings outside strict mode, and an ES5 spec bug,
spanning 20101124-20101126. I don't know whether any followup happened to fix that or
not in the spec, haven't been concerned enough to
On 21/03/2011, at 00:21, Bradley Meck wrote:
It isn't in the past though, it is scheduled to be run as soon as
possible past a certain point. That being said `as soon as possible`
may not be in a particular order (os schedulers / threads / event
listeners in js for example). I view this close
On 3/21/11 4:40 AM, Erik Corry wrote:
You want to protect the user from a compromise of Mozillas servers,
We also want to protect the user from a subpoena served to Mozilla, for
example. This means we must never have the data on our side, and this
means the encryption needs to happen on the
Just FYI, you are going to run into the problem of key portability. If the
key is derived from a password, your encrypted copy of the user's data
(which might be subject to subpoena?) could be easily cracked via offline
dictionary attacks. I hope you at least plan to use a salt, many iterations
of
I was looking forward to a Javascript with block scope at last,
but on looking through the proposals, I have some questions:
1. hoisting vs recursive function definitions
Hoisting isn't nice in general, and from the no use before
declaration in [1], it seems that let bindings won't be
On Mar 20, 2011, at 11:30 PM, Andrew Dupont wrote:
Java doesn't formalize this, you're right — but if I'm looking at
`this.doSomething()` and wondering about its visibility, I can look in the
class definition itself (to see if it's private) or in one of its
superclasses (to see if it's
https://wiki.mozilla.org/Labs/Weave/Developer/Crypto
Let's get back to es-discuss, ok?
/be
On Mar 21, 2011, at 8:58 AM, Shabsi Walfish wrote:
Just FYI, you are going to run into the problem of key portability. If the
key is derived from a password, your encrypted copy of the user's data
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
Right now, everything that can be expressed via dot notation has an analog in
bracket
Brendan and Irakli both beat me to the punch here -- I would really like to see
stronger evidence that an entire lexical scope is really so onerous.
Everything you say about how Java mitigates the problem is just as applicable
to Harmony.
Java doesn't formalize this, you're right — but if I'm
On Mon, Mar 21, 2011 at 6:54 PM, Peter van der Zee e...@qfox.nl wrote:
On Fri, Mar 11, 2011 at 12:12 AM, Luke Smith lsm...@lucassmith.namewrote:
The consistent behavior across all browsers of Date when passed a time
made invalid by a DST jump is to roll the time *back* by an hour.
// On a
On 3/18/11, Kyle Simpson get...@gmail.com wrote:
There's LOTS of sites out there that still (unfortunately) do unsafe
overwriting/overloading of the native's prototypes. For instance, just a few
months ago, I ran across a site that was creating a Array.prototype.push()
implementation that was
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
The Harmony top-level scope (no global object!) will be big and it may even
This is a bug in the spec, and has been previously discussed here:
https://mail.mozilla.org/pipermail/es5-discuss/2010-November/003839.html
(Thanks, Jeff!)
On 03/20/2011 11:22 PM, Jim Blandy wrote:
When executing this code:
(function () {
eval(var x=delete(x))
})()
I think
On Mar 21, 2011, at 11:29 AM, Andrew Dupont wrote:
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
The Harmony top-level
Hoisting isn't nice in general, and from the no use beforedeclaration
in [1], it seems that let bindings won't be hoisted,
not even to their enclosing block.
That page is not yet complete. There's plenty more work to do on it, but we
probably won't be able to find much time to do
This is now https://bugs.ecmascript.org/show_bug.cgi?id=79
On Mar 21, 2011, at 11:44 AM, Jim Blandy wrote:
This is a bug in the spec, and has been previously discussed here:
https://mail.mozilla.org/pipermail/es5-discuss/2010-November/003839.html
(Thanks, Jeff!)
On 03/20/2011 11:22
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to fit
this scenario.
Extending built ins
On Mon, Mar 21, 2011 at 19:29, Andrew Dupont mozi...@andrewdupont.netwrote:
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
Hi Andrew, thanks for the good thinking on this thread. I'm not
cherry-picking here, but I wanted to reply to the specific sentence ending
entire lexical scope.
Erik,
Yes, this is exactly what a framework like Prototype would need. Your code is
highly reminiscent of Ruby's proposed refinements feature [1], one which is
being debated for inclusion in Ruby 2.0. If this could be implemented in a way
that avoids the dreaded namespace dragons, then I would
Hi,
Proxies can be helpful to emulate multiple inheritance
(http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/).
Long story short, with the get and set traps, you can emulate this
multiple inheritance without having the required prototype chain.
However, since
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to
On Mon, Mar 21, 2011 at 16:45, Waldemar Horwat walde...@google.com wrote:
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or
Started implementation of collator in Chrome and hit a problem:
var coll = locale.collator();
array.sort(coll.compare);
Compare method gets bound to the undefined or global object at the call
site. Erik mentioned that this problem will be solved in Harmony by passing
additional this parameter to
On Mon, Mar 21, 2011 at 17:28, Nebojša Ćirić c...@google.com wrote:
Started implementation of collator in Chrome and hit a problem:
var coll = locale.collator();
array.sort(coll.compare);
Compare method gets bound to the undefined or global object at the call
site. Erik mentioned that this
Sorry, I didn't get the difference first time around.
Also, current fix is to do:
array.sort(function(a,b) { return coll.compare(a,b); });
21. март 2011. 17.31, Erik Arvidsson erik.arvids...@gmail.com је
написао/ла:
On Mon, Mar 21, 2011 at 17:28, Nebojša Ćirić c...@google.com wrote:
Started
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
Erik, I'm not sure that my understanding of the intended semantics of your
extension statement is totally correct. But given what I
On 03/21/11 17:42, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
Erik, I'm not sure that my understanding of the intended semantics of your
extension
On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
You'd still run into all of the issues caused by private filter behaving
like a C++ #define. For example:
var foo = {filter: 34};
then pass foo to an outside client.
Trying to interpret your comment. Are you saying that the above
Hi David, are you aware of
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof?
I just heard from Brendan today that Andreas Gal has encountered some DOM
emulation issues that might make us want us to consider this sooner rather
than later. How well would it also address the cases
On Mon, Mar 21, 2011 at 5:37 PM, Nebojša Ćirić c...@google.com wrote:
Sorry, I didn't get the difference first time around.
Also, current fix is to do:
array.sort(function(a,b) { return coll.compare(a,b); });
Why not
array.sort(coll.compare.bind(coll))
?
21. март 2011. 17.31,
We had discussed that. Would it make sense to specify that coll.compare
would actually be a bound method? That's one of the things that had a
little oh, no good any way we do this, as Erik wouldn't know of any
example we'd follow by defining a method on an object to be bound by
default.
Axel
On Mon, Mar 21, 2011 at 6:37 PM, Axel Hecht a...@mozilla.com wrote:
We had discussed that. Would it make sense to specify that coll.compare
would actually be a bound method? That's one of the things that had a little
oh, no good any way we do this, as Erik wouldn't know of any example we'd
Hey Allen,
The use case runs something like this:
Suppose you use a collection library which has 'filter' implemented on all
of their collections. So we have Set.prototype.filter, Map.prototype.filter,
Tree.prototype.filter, etc. But the library doesn't add Array.filter because
monkey patching
On Mar 21, 2011, at 6:17 PM, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
You'd still run into all of the issues caused by private filter behaving
like a C++ #define.
#define exagerrates.
For example:
var foo = {filter: 34};
then pass foo to an
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
{
extend Object.prototype with {
filter: function(fun) {
var retval = {};
for (var key in this) {
if (fun(this[key])
retval[key] = this[key];
}
return retval;
}
};
function largerThanN(obj, n) {
return
37 matches
Mail list logo
