Smart. These would be like the dict proposal [1].
It might make sense to encapsulate this, e.g. as a constructor StringMap.
Rationale: allows you to use a shim on older systems. And you have to change
existing code, anyway.
In the shim, one could avoid creating excess garbage by only prefixing
Aren't you assuming a certain kind of guards, namely converting rather than
throwing? There's no way to future-proof without more agreement on what the
default meaning of x :: Number would be, and (AFAIK) we don't have consensus
yet.
Anyway, no one is going to start writing imperative
I concur...
In addition, a standardized, built-in debugger API would also be nice... there
was the Crossfire effort but I'm not sure where that ended up or who is
supporting it.
I'm not sure how others feel about standardizing such 'meta features' of the
language, but I'm all for such
IIRC, the block lambda proposal covers this (pun might be intended)
window.foo = function() {
console.log(hi!);
};
window.addEventListener('load', {||
this.foo(); // hi!
}, false);
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival#semantics
Rick
On Thu, Dec 29, 2011
Sorry if this has been suggested before
I've stopped using the 'self=this' trick:
...
var self = this;
window.addEventListener('load', function(event) {
self.foo();
}, false);
in favor of bind():
...
window.addEventListener('load', function(event) {
this.foo();
We should probably avoid pressures for the build-ins to cover all possible
use cases. In ES.next we will should have all the primitives necessary for JS
programmers to define their own efficient collection objects, including
various kinds of hash-tables. Hopefully some good libraries of
On Dec 29, 2011, at 6:34 AM, Axel Rauschmayer wrote:
We should probably avoid pressures for the build-ins to cover all possible
use cases. In ES.next we will should have all the primitives necessary for
JS programmers to define their own efficient collection objects, including
various
Once we have type guards, I would expect the JavaScript programming style to
slightly change. Currently, number-valued arguments are implemented like this:
function foo(x) {
x = Number(x);
}
With guards, you would use:
function foo(x :: Number) {
}
It might make sense
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__' in object literals should work like any property.
The ES.next proto operator [1] creates a standard alternative to using
__proto__ in object literal.
As the
On Dec 29, 2011, at 3:38 AM, Lasse Reichstein wrote:
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
__proto__ property.
Not if
Hi Allen, that's very clever. But I don't think it is needed.
David is right about running first. I also don't have a proof, but
practically I'm sure that for JS as it is and will continue to be under
ES-next, unless some trusted code runs in a context (frame) to initialize
itself before any
Le 29/12/2011 12:38, Lasse Reichstein a écrit :
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
__proto__ property.
That means that
On Dec 28, 2011, at 10:14 PM, Mark S. Miller wrote:
On Wed, Dec 28, 2011 at 10:06 PM, Brendan Eich bren...@mozilla.com wrote:
From: Mark S. Miller erig...@google.com
I take it you are simply reiterating the desire for a standard system
provided high entropy object-identity hash that is
On Dec 28, 2011, at 6:48 PM, Mark S. Miller wrote:
...
Likewise, I expect that detecting misbehavior sort comparison functions is
too hard to be practical. However, I strongly disagree that the current
underspecification isn't a problem. How undefined is this behavior?
(Actually, the
Le 29/12/2011 05:08, Mark S. Miller a écrit :
On Wed, Dec 28, 2011 at 6:48 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
[...]
For example, regarding sorting, leaving aside sparseness, I
suspect our shared model is that any sort algorithm implementation
I’m not sure that there is much one can do to protect programmers from
themselves, given that writing good hash functions is hard. One could provide a
test suite.
Random thoughts:
- Enforce that both equality and hash function are specified. A common Java
problem.
- Provide a hash function
It’d be nice if stack traces were standardized. Are there any plans to do so?
The following project could be used for shims:
http://stacktracejs.org/
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
__proto__ property.
That means that if you're not the first script to run on a page, you
On Thu, Dec 29, 2011 at 9:13 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
Personally, given that IE as yet to support it, I think there is a good
argument that the intersection semantics is empty and at the very least
__proto__ in object literals it should be banned in ES.next
On Thu, Dec 29, 2011 at 9:48 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
For example, regarding sorting, leaving aside sparseness, I suspect our
shared model is that any sort algorithm implementation itself takes only
the following observable steps, but in some arbitrary order and
Le 29/12/2011 18:13, Allen Wirfs-Brock a écrit :
On Dec 29, 2011, at 4:58 AM, David Bruant wrote:
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__' in object literals should work like any property. The
So I was digging through repairES5.js
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#1427
and noticed that:
var a = Object.freeze({ 'x': 1 });
var b = Object.create(a);
b.x = 2;
b.x; // should still be 1
Then I dug into spec and noticed:
Hi David, that's a good point. ES-next will have three modes, IIRC
currently called non-strict, strict, and extended. (ES5 and ES-next
non-strict is effectively an ES3 compatibility mode and ES-next strict is
effectively an ES5-strict compatibility mode.) As with ES5's non-strict
vs strict, these
[+google-caja-discuss]
Hi John,
First, thanks for commenting on repairES5.js. Please keep the comments
coming. Anything not appropriate for the es-discuss like should instead be
posted to google-caja-discuss, cc'ed. But please look instead at
Aren't you assuming a certain kind of guards, namely converting rather than
throwing? There's no way to future-proof without more agreement on what the
default meaning of x :: Number would be, and (AFAIK) we don't have consensus
yet.
Yes, in the future of JavaScript, I’d expect more
On Dec 29, 2011, at 2:00 PM, David Bruant wrote:
Le 29/12/2011 18:13, Allen Wirfs-Brock a écrit :
On Dec 29, 2011, at 4:58 AM, David Bruant wrote:
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__' in
Yes, block lambdas are awesome and will nearly eliminate the dynamic this
versus lexical this quirk from JavaScript.
var obj = {
foo: function () {
console.log(hi!);
},
bar: function () {
// block lambdas = lexical `this`
// = picks
I’m curious: Is it likely that such libraries will get written by the
community? This domain does not seem to enjoy much interest. (I would
volunteer, but have neither the necessary expertise/experience nor the time.)
Well, If nobody else creates such a library, I will.
+ Number.MAX_VALUE
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller erig...@google.com wrote:
Hi Allen, that's very clever. But I don't think it is needed.
David is right about running first. I also don't have a proof, but
practically I'm sure that for JS as it is and will continue to be under
ES-next, unless
Le 30/12/2011 01:00, Lasse Reichstein a écrit :
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller erig...@google.com wrote:
Hi Allen, that's very clever. But I don't think it is needed.
David is right about running first. I also don't have a proof, but
practically I'm sure that for JS as it is
Hi John,
Your particular syntactic choice looks clever, but as is often the case, it
fails because of semicolon insertion. The following works today on any ES5
system:
function foo() { return this.function() { console.log('oops'); };
}
foo.call({function: function(){return 'gotcha';}});
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com wrote:
Le 30/12/2011 01:00, Lasse Reichstein a écrit :
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller erig...@google.com
wrote:
I've been thinking about this run first idea for some time. Since on a
webpage, security seems to
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com wrote:
[...]
If you do not run first, the attacker can make the environement look
like a normal one. Specifically, you can try to do
Object.defineProperty(Object.prototype, '__proto__',
{configurable:false}) and the attacker can
33 matches
Mail list logo
