ed very well for me in past projects.
-Mike
_
From: Yehuda Katz
Sent: Friday, October 03, 2008 7:01 PM
To: jquery-dev@googlegroups.com
Subject: [jquery-dev] Re: Immunizing jQuery against enviroment changes
Michael,
the iframe trick requires proxying of things like window, document, etc,
console.log("raw time", +new Date - start);
+new Date --> Yeah!
>
> start = +new Date;
> for (var i = 0; i < 1000; i++) {
>var tainted = Object.tainted();
>for (var key in test) {
>if (!tainted || !Object.prototype[key]) {
>fn(key, test[key
My primite micro benchmark:
function fn(key, value) {
var result = key + value;
}
var test = {};
for (var i = 0; i < 1000; i++) {
test["testkey" + i] = "test" + i;
}
var start = +new Date;
for (var i = 0; i < 1000; i++) {
for (var key in test) {
fn(key, te
Michael,
the iframe trick requires proxying of things like window, document, etc, no?
Whenever I've thought about it before it seemed prohibitively complex.
-- Yehuda
On Fri, Oct 3, 2008 at 6:41 PM, Michael Geary <[EMAIL PROTECTED]> wrote:
> I suppose it's arguable what's easier - after all if
I suppose it's arguable what's easier - after all if it were *that* easy I
would have had that patch done already. :-) But I used the iframe trick on a
widget project where I needed to be compatible with just about any website
out there, and it really works well.
_
From: Michael Geary
If you really want to protect against changes to native objects, load jQuery
into a private IFRAME. It's easier than all these tricks, and it gives
absolute protection.
I have 90% of a patch to do this - I know I promised it a while ago - been
kind of busy with election stuff for Google. But I'll
I suppose (and expect) the for in loop is the fastest one, since it works in
core and does not require increments ( i++ or ++i )
push "is slow" if applied manually, and "events[events.props[i]]" is a sort
of "double hash search" for each iteraction.
But, tt this point, I miss the purpose of the o
The push would happen only when new events were added, which is rarely if
ever on the critical path.
A more optimized version of the for loop:
var props = events.props
for(var i=0, j=props.length, i wrote:
> I suppose (and expect) the for in loop is the fastest one, since it works
> in core and d
Just to be clear what I'm talking about:
say we have something like:
events = {}
events.foo = 17
events.bar = 19
and then
for(var prop in events) {
// do stuff with foo and bar
}
we could instead do something like:
events = {}
events.props = []
events.foo = 17
events.props.push("foo")
events
Ariel forget it, I posted a silly code since in that way of course I am
redefining undefined variable, while null is not redefinable :-)
if (!Object.prototype[key])
I am thinking if
var o = {}, key;
and in the loop
if (!(key in o)) ...
should work faster ... or maybe not ?
On Fri, Oct 3, 2008
Different cases here possibly call for different approaches.
In the case (like in events), where we're in charge of setting up the keys,
why not keep a separate Array around with a list of the keys. I'm talking,
for instance, about line 306 and 307 in core.js.
In certain other cases (like setting
null is faster than undefined. Is that legal js syntax ? (going to try it)
On Fri, Oct 3, 2008 at 2:30 PM, Andrea Giammarchi <
[EMAIL PROTECTED]> wrote:
> Will it speed up?
>
> Object.tainted = function(){
> for(undefined in{})
> returntrue;
> returnfalse;
> };
>
>
>
> On
Indeed. undefined works, null doesn't.
On Fri, Oct 3, 2008 at 2:30 PM, Andrea Giammarchi <
[EMAIL PROTECTED]> wrote:
> Will it speed up?
>
> Object.tainted = function(){
> for(undefined in{})
> returntrue;
> returnfalse;
> };
>
>
>
> On Fri, Oct 3, 2008 at 6:27 PM, Ariel F
Will it speed up?
Object.tainted = function(){
for(undefined in{})
returntrue;
returnfalse;
};
On Fri, Oct 3, 2008 at 6:27 PM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
> Yeah, I think the same. I think the env is tainted if you ADD a new method.
> Of course modifying St
Yeah, I think the same. I think the env is tainted if you ADD a new method.
Of course modifying String.prototype.split would also taint it but I don't
think anyone will do that w/o making it backwards compatible to the native
method.
The main concern, I think, is perfomance. I'd like to see some b
Hi John,
mine was only a notice about the "for in" trick.
It is not only about toString, it is about every native prototype method, if
redefined.
The problem is even worst with IE, dunno yet with version 8.
About performances, that's a core loop never performed, or performed only
once thanks to t
> alert(Object.tainted()); // false
> alert({}); // wof wof
I think we're ok with that case - since we only want to prevent jQuery
from breaking when the Object.prototype is manipulated (diddling with
the Object.prototype.toString method would be weird, but it wouldn't
affect how jQuery works, I
I meant that its running only once for a full iteration, instead of
running for each iteration. As long as the call is made before
starting the iteration, it should be safe enough. Of course a callback
could still taint it...
Jörn
On Fri, Oct 3, 2008 at 7:01 PM, Ariel Flesler <[EMAIL PROTECTED]>
> I don't see it running only once from the code you showed.
> In addition, you can't assure the environment will remain "untainted"
> after you call this function for the first time (assuming you cache
> this value).
Yeah, that's the tricky part. If someone included json.js after jQuery
it would
Ariel,
that is my "favourite" version as well, but it could fail in some case, e.g.
Object.tainted = function() {
for (var key in {})
return true;
return false;
};
Object.prototype.toString = function(){
return "wof wof";
};
alert(Object.tainted()); // false
alert({
I don't see it running only once from the code you showed.
In addition, you can't assure the environment will remain "untainted"
after you call this function for the first time (assuming you cache
this value).
By the way, here's my modified version:
Object.tainted = function() {
for (var
The tainted-check runs just once, so for a non-tainted enviroment you
avoid the overhead of the check. I don't know if that actually makes a
difference.
Jörn
On Fri, Oct 3, 2008 at 6:37 PM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
>
> This is nothing new I think. The typical "safe" for..in iterat
This is nothing new I think. The typical "safe" for..in iteration.
I don't quite see the point of the tainted function. I just see one
for..in iteration split into 2, and actually with extra overhead.
May I get some enlightenment ? :)
--
Ariel Flesler
http://flesler.blogspot.com
On Oct 3, 1:27
23 matches
Mail list logo
