Le 05/10/2011 10:33, Mark S. Miller a écrit :
Since you're assuming you can initialize and grab stuff before your
context is corrupted, what's wrong with Lasse's earlier (and very
clever!)
var call = Function.prototype.call.bind(Function.prototype.call);
and by direct analogy:
var apply = Function.prototype.call.bind(Function.prototype.apply);
var bind = Function.prototype.call.bind(Function.prototype.bind);
?
Nothing's wrong. I forgot about this, sorry. It is indeed very clever.
I take back what I said about the necessity of a syntax construct for bind.
David
If there's a vulnerability with this technique, I need to know that
asap, as I'm about to start writing code that depends on it for
security. So any vulnerabilities you or anyone can point out now will
be greatly appreciated. Thanks.
On Wed, Oct 5, 2011 at 10:24 AM, David Bruant <david.bru...@labri.fr
<mailto:david.bru...@labri.fr>> wrote:
Le 05/10/2011 10:17, Lasse Reichstein a écrit :
On Tue, Oct 4, 2011 at 6:19 PM, David Bruant
<david.bru...@labri.fr <mailto:david.bru...@labri.fr>> wrote:
I sent a message here explaining the necessity of a syntax
construct for a reliable bind [1]. There is a need to
investingate (one reply was very close from a solution) to
make sure that such a thing is not possible in pure ES5
(without making Function.prototype.bind non-configurable),
but that would be one such thing that no language compiling
to JavaScript could emulate (since impossible in the language
itself).
I don't think "security" from malicious changes to
Function.prototype.bind is a good argument for adding new
operator syntax.
The problem doesn't stop with Function.prototype.bind. ES5 as a
compilation target is built on a quagmire since almost all
fundamental language operations are methods that can be changed.
The operators are the exception, since you can't override their
meaning[1], and I can see why you wish to introduce
modification-safe operators for the operations you want to
preserve - but why is Function.prototype.bind more important
than, say, Math.pow?
The difference I saw is that you can keep a reference to Math.pow
within a scope of yours and you'll be fine. Such a thing doesn't
seem possible with call, apply and bind, mostly because you need
to rely on at least one of them in order to do call.call or
call.bind, etc. and consequently, you always depend on the value
on Function.prototype.* in a way or another.
As i said before, there is a reliable way to do a call which is
f(), but you can't choose the value of |this|. That's what
originally motivated the idea of a syntax-based bind.
I don't think that the other functions require such a thing.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
