On 9 November 2011 00:16, Mark S. Miller erig...@google.com wrote:
On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg rossb...@google.com
wrote:
On 8 November 2011 20:46, Mark S. Miller erig...@google.com wrote:
Nevertheless, I see your point. Many defensive ES5 abstractions will be
less
On Tue, Nov 8, 2011 at 4:58 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
Perhaps we should
be more conservative here, without necessarily backing away from the
whole
Proxy.attach idea?
Disallowing attaching to functions with your own call/construct traps
would be the minimal
Le 08/11/2011 14:26, Andreas Rossberg a écrit :
On 3 November 2011 23:55, Mark S. Miller erig...@google.com wrote:
If I understood Mark correctly, the features needed for SES are
already part of ES.5 and are shipping in browsers
(and hence don't bear upon future features). Did I
On Tue, Nov 8, 2011 at 5:26 AM, Andreas Rossberg rossb...@google.comwrote:
On 3 November 2011 23:55, Mark S. Miller erig...@google.com wrote:
If I understood Mark correctly, the features needed for SES are
already part of ES.5 and are shipping in browsers
(and hence don't bear upon
On 8 November 2011 18:47, David Bruant bruan...@gmail.com wrote:
Given that direct proxies are not in a position to violate any of the
*non-configurability or non-extensibility constraints* of their wrapped
target, it should be safe to replace an existing normal object by a
direct proxy
On 8 November 2011 20:29, Andreas Rossberg rossb...@google.com wrote:
On 8 November 2011 18:47, David Bruant bruan...@gmail.com wrote:
Given that direct proxies are not in a position to violate any of the
*non-configurability or non-extensibility constraints* of their wrapped
target, it should
On Tue, Nov 8, 2011 at 11:29 AM, Andreas Rossberg rossb...@google.comwrote:
On 8 November 2011 19:13, Mark S. Miller erig...@google.com wrote:
The reason Proxy.attach may not be fatal is that it only allows
attachment
to extensible objects. Our hypothesis is that any ES5 object that is
On 8 November 2011 20:46, Mark S. Miller erig...@google.com wrote:
In general, for an object to be defensive, much of the surface reachable
from it by transitive prototype and reflective property traversal should
usually be frozen, and at least non-extensible. This is possible to express
in
On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg rossb...@google.comwrote:
On 8 November 2011 20:46, Mark S. Miller erig...@google.com wrote:
Nevertheless, I see your point. Many defensive ES5 abstractions will be
less
defensive than this. If I understand you correctly, your point is
Perhaps __proto__ should not be writeable in use strict?
That's a great idea! This never occurred to me, and I have not heard anyone
suggest this. Thanks!
Doesn't work.
obj[(function(__){return __ + proto + __})(__)]
Dave
___
es-discuss
On Tue, Nov 8, 2011 at 3:33 PM, David Herman dher...@mozilla.com wrote:
Perhaps __proto__ should not be writeable in use strict?
That's a great idea! This never occurred to me, and I have not heard
anyone suggest this. Thanks!
Doesn't work.
obj[(function(__){return __ + proto +
On Tue, Nov 8, 2011 at 3:46 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Nov 8, 2011 at 3:33 PM, David Herman dher...@mozilla.com wrote:
Perhaps __proto__ should not be writeable in use strict?
That's a great idea! This never occurred to me, and I have not heard
anyone suggest
http://www.google.com/support/forum/p/Google+Docs/thread?tid=0cd4a00bd4aef9e4
But yes. Because the difference would be silent, I'm skeptical too.
On Tue, Nov 8, 2011 at 8:23 PM, David Herman dher...@mozilla.com wrote:
And another silent semantic change? I wouldn't be so quick to do that. And
One more thought: people are already avoiding use strict; because it bites
back:
* concatenation with non-strict code and under-testing, but let's hope we are
past this now;
* performance dinged a bit by strict mode, or at least non-strict calling
strict and vice versa.
We should try to avoid
In .. an ES5/strict environment in which all primordial built-in objects
are transitively frozen, ..
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) {
On Nov 4, 2011, at 8:50 AM, Juan Ignacio Dopazo wrote:
On Thu, Nov 3, 2011 at 7:55 PM, Mark S. Miller erig...@google.com wrote:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) {
On Fri, Nov 4, 2011 at 8:14 AM, Claus Reinke claus.rei...@talk21.comwrote:
Hm. A favorite pattern that I haven't thought about enough, it seems.
My curiosity did cost me some sleep:-| My favorite work around for
your constraints is this little shim:-)
// dynamic language
Object.freeze =
[edited and sent to es-discuss, just in case]
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
[...] Given
function Bob(t) {
var stolenArray;
var hackedPush = function() {
stolenArray = this;
};
t.store(push, hackedPush);
t.add(0);
console.log(stolenArray);
}
Bob(makeTable());
As an aside: This problem would go away if we really did
On 03/11/2011, at 23:55, Mark S. Miller wrote:
3) Although SES is *formally* an object-capability language, i.e., it has all
the formal properties required by the object-capability model, it has bad
usability properties for writing defensive abstractions, and therefore bad
usability
On Nov 4, 2011, at 10:33 AM, Axel Rauschmayer wrote:
How about:
function Bob(t) {
var stolenArray;
var hackedPush = function() {
stolenArray = this;
};
t.store(push, hackedPush);
If Array.prototype has been frozen (as the problem statement implied)
On 04/11/2011, at 18:51, Jorge wrote:
On 03/11/2011, at 23:55, Mark S. Miller wrote:
3) Although SES is *formally* an object-capability language, i.e., it has
all the formal properties required by the object-capability model, it has
bad usability properties for writing defensive
But hackedPush is added to the instance, not Array.prototype.
On Nov 4, 2011, at 18:59 , Allen Wirfs-Brock wrote:
On Nov 4, 2011, at 10:33 AM, Axel Rauschmayer wrote:
How about:
function Bob(t) {
var stolenArray;
var hackedPush = function() {
stolenArray = this;
You can't over-ride an inherited read-only property by assignment. See ES5.1
8.12.4
You could do it via Object.defineProperty, but that requires direct access to
the object.
Allen
On Nov 4, 2011, at 11:01 AM, Axel Rauschmayer wrote:
But hackedPush is added to the instance, not
This is the only one I've seen that seems like it should work, but it depends
on whether SES/Caja/etc have some sort of way of neutering __proto__. Just from
hacking around, I don't see much way of censoring it in SpiderMonkey.
MarkM, do you have any tricks for censoring __proto__?
Dave
On
// dynamic language
Object.freeze = function(obj){return obj};
You imply that this is not intended, so I can show it without spoiling
the fun. I was surprised that this works.
Since the primordials are already frozen, this assignment fails.
Yes. It just re-emphasizes the need to be the
On Nov 4, 2011, at 2:40 PM, Allen Wirfs-Brock wrote:
On Nov 4, 2011, at 2:33 PM, Brendan Eich wrote:
...
If you could redefine [] as an operator on all objects, perhaps that would
help. Or hurt. Both, probably. That isn't what Allen proposes, though. It
would have to be universal AFAICT.
On Nov 4, 2011, at 2:49 PM, Brendan Eich wrote:
On Nov 4, 2011, at 2:40 PM, Allen Wirfs-Brock wrote:
On Nov 4, 2011, at 2:33 PM, Brendan Eich wrote:
...
If you could redefine [] as an operator on all objects, perhaps that would
help. Or hurt. Both, probably. That isn't what Allen
On Fri, Nov 4, 2011 at 10:33 AM, Axel Rauschmayer a...@rauschma.de wrote:
How about:
function Bob(t) {
var stolenArray;
var hackedPush = function() {
stolenArray = this;
};
t.store(push, hackedPush);
t.add(0);
console.log(stolenArray);
So Object.prototype customization would cover all cases? Except Proxies, of
course -- and host objects.
Yes, except that what you would expect to put into Object.prototype would
actually (or also) be defined as default behavior in order to ensure that
that Object.create(null) objects,
On Fri, Nov 4, 2011 at 10:37 AM, Axel Rauschmayer a...@rauschma.de wrote:
function Bob(t) {
var stolenArray;
var hackedPush = function() {
stolenArray = this;
};
t.store(push, hackedPush);
t.add(0);
console.log(stolenArray);
}
On Fri, Nov 4, 2011 at 10:51 AM, Jorge jo...@jorgechamorro.com wrote:
o= makeTable();
o.add(1);
o.add(2);
o.add(3);
o.add('Yay!');
o.store('__proto__', {push:function () { console.log(this) }});
o.add();
Gives:
[ 1, 2, 3, 'Yay!' ]
Very nice! Your use of __proto__ is very clever,
As an aside: This problem would go away if we really did distinguish between
accessing a property and accessing a collection element. Then the former
would be done via Object.* methods, while the latter would be done via square
brackets.
I admit that I haven't followed the previous
On Fri, Nov 4, 2011 at 11:46 AM, David Herman dher...@mozilla.com wrote:
This is the only one I've seen that seems like it should work, but it
depends on whether SES/Caja/etc have some sort of way of neutering
__proto__. Just from hacking around, I don't see much way of censoring it
in
On Fri, Nov 4, 2011 at 12:11 PM, Claus Reinke claus.rei...@talk21.comwrote:
// dynamic language
Object.freeze = function(obj){return obj};
You imply that this is not intended, so I can show it without spoiling
the fun. I was surprised that this works.
Since the primordials are already
On Fri, Nov 4, 2011 at 6:50 PM, Axel Rauschmayer a...@rauschma.de wrote:
I agree completely (see also my other email):
- Never use objects as maps.
- Introduce collection classes.
- Try to make arrays fit into the collection framework.
Great! But could you please post a pointer to that
On Fri, Nov 4, 2011 at 2:33 PM, Brendan Eich bren...@mozilla.com wrote:
If you could redefine [] as an operator on all objects, perhaps that would
help. Or hurt. Both, probably. That isn't what Allen proposes, though. It
would have to be universal AFAICT. Thoughts?
Is there a previous email
I agree completely (see also my other email):
- Never use objects as maps.
- Introduce collection classes.
- Try to make arrays fit into the collection framework.
Great! But could you please post a pointer to that other email, or post a
summary? Thanks.
This is the original thread:
On Nov 4, 2011, at 6:44 PM, Mark S. Miller wrote:
On Fri, Nov 4, 2011 at 10:37 AM, Axel Rauschmayer a...@rauschma.de wrote:
As an aside: This problem would go away if we really did distinguish between
accessing a property and accessing a collection element. Then the former
would be
On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
. Also, I heartily recommend the talks to
those not entirely convinced of the necessity of private/const/frozen
features. Mark makes a pretty good case for encapsulation as a necessary
building block for ocap-based
On Thu, Nov 3, 2011 at 2:10 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem tomvc...@gmail.com
wrote:
. Also, I heartily recommend the talks to
those not entirely convinced of the necessity of private/const/frozen
features. Mark makes a
On 11:59 AM, Mark S. Miller wrote:
Note that I don't see any realistic way to fix problem #3 in the
ES.next language. My point is only that defensive programming is
tricky even after you've gotten all the formal properties you need. As
ES.next introduces various new abstraction mechanisms,
42 matches
Mail list logo
