there is no security issue ... it's meant like that plus what Mark did not
think about, is that if I use
(function () {
function callback() {}
var object = {};
window.addEventListener("no way", object.boundTo(callback), false);
// later on
window.removeEventListener("no way", object.boundTo(callback), false);
}());
inside a scope other objects can not reach, nobody will ever be able to
retrieve the resulting bound function/object.
The security issue is indeed all over *now* with current way to store bound
once callbacks per object.
object._boundMethod = object.method.bind(object);
Above pattern is able to destroy entire framework but nobody ever
complained ... well, glad to be the first one.
br
On Fri, Jan 6, 2012 at 4:23 PM, David Bruant <bruan...@gmail.com> wrote:
> Le 06/01/2012 12:51, Andrea Giammarchi a écrit :
>
> unreachable without reference count? do you have an example different
>> from a private scope object that is reachable from that scope so I would
>> not call it unreachable?
>>
> I'm not sure I understand your question.
> In IE6 (7? 8?), written naively, event handlers often had a reference to
> the element they were bound to (via scope chain) and the element had a
> reference to the handler (obviously). It created a cycle that reference
> counting based GC was unable to collect.
> Mark-and-sweep GCs don't have this problem at all. It doesn't prevent
> every memory leak (no GC can), but is far more efficient in obvious cases
> than reference counting.
>
>
> In any case I understand your leaks point and if WeakMap solves this, but
>> I strongly believe no shim will be able to emulate this behavior, no
>> matters how much articulated the implementation is ( taking that google
>> shim as example that also won't work as it is in older browsers in any case
>> )
>>
> Yes, in older browser, any implementation of what you want would leak in
> some cases.
>
>
> Then this is a dead line, something that you said makes sense as problem,
>> won't be solved natively because it can be implemented via libraries ...
>> but if this is the logic, I wonder what is ES5 about with all its extras (
>> Array, Function, String, etc )
>>
> I would guess uniformisation of very frequent patterns (forEach, map,
> filter...), a need for a reliable isArray method that some libraries got
> right and other completely wrong.
> ES5 was far more that these shimable extras: strict mode, fine grained
> property control, getters/setters to name a few.
> There was probably also some "evangelisation" or "politics". Take
> Object.create. Besides the second argument, it can be shimed. Yes, but
> having this fundamental construct also helps a lot in understanding and
> teaching the language.
>
> Also, I did not say that everything that can be done with a library should
> not be part of the language. I'm in priority interested in seeing in the
> language things that cannot be done (at all or efficiently) with a library.
> That's just a priority (of mine, by the way. I haven't seen an expression
> of TC39, but the current list of proposal speaks for itself, I think)
> It seems that it has been in JavaScript from the beginning that the
> language provides basic bricks and people can feel free to create
> themselves what they want/need on top of that.
>
> Some patterns were very common and have later been integrated into the
> language.
> Some functions could probably be made far more efficient or reliable when
> integrated in the language.
>
> I think that bringing in the language things that can be implemented in
> libraries should be justified by more than a use case. For instance, I'm
> enthusiastic of promises [1], these are more and more used, there are a lot
> of different APIs. It will be interesting to see what wins and bring this
> to ECMAScript when it seems promises have been "explored".
>
> But I still don't see a strong justification in a memoized bind. I
> understand and agree with the use case, but it doesn't seem enough to bring
> it into the core language (and you haven't answered the security concern
> raised by Mark...)
>
> David
>
> [1]
> http://wiki.ecmascript.org/**doku.php?id=strawman:**concurrency<http://wiki.ecmascript.org/doku.php?id=strawman:concurrency>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
