But isn’t jQuery.bar() just a work-around, because JavaScript does not have
modules, yet?
On Oct 30, 2011, at 21:05 , Rick Waldron wrote:
This pattern makes is _very_ easy for newer developers/adopters to understand
the division of functionality:
- DOM methods here: jQuery().foo()
-
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.
No, not at all. It's a conscious design decision that results in only
introducing one new property to the global object (two if you count the
shorthand reference to $)
Rick
On Fri, Nov 4, 2011 at 11:00 AM, Axel Rauschmayer a...@rauschma.de wrote:
But isn’t jQuery.bar() just a work-around,
When I see singleton objects in JavaScript, I mostly consider them poor man’s
modules (including the Object.* methods).
You could write a jQuery module that exports the “everything else” functions
and the identifiers $ and jQuery for the DOM stuff.
On Nov 5, 2011, at 0:28 , Rick Waldron wrote:
...But that's not the point. The point is to have a _single_ namespaced,
unified API; this helps keep the library small, reduces potential conflict
with other libs, makes it easier to learn, easier to extend and easier to
maintain.
jQuery deals in reality, not the fantasy world of spec drafts and
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
29 matches
Mail list logo
