Re: Re: What is the status of Weak References?

Thank you for the link, I'm glad to see that people have been making progress on it. On Fri, Jul 21, 2017 at 2:16 PM, Isiah Meadows wrote: > This is probably best asked/stated here: > https://github.com/tc39/proposal-weakrefs/ > - > > Isiah Meadows >

Re: Re: What is the status of Weak References?

This is probably best asked/stated here: https://github.com/tc39/proposal-weakrefs/ - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Thu, Jul 20, 2017 at 6:26 PM, Owen

Re: Re: What is the status of Weak References?

I see this is a very old thread, but I was wondering if there have been any new developments/plans? My thoughts are this: I think it's natural, if you're used to seeing people misuse GC, to be suspicious of weakrefs. With GC it's easy to create accidental memory leaks because you think the

Re: A WeakMap where values (not keys) are weak references?

BTW are the security concerns mentioned by Erik Arvidsson in this thread (http://mozilla.6506.n7.nabble.com/What-is-the-status-of-Weak-References-tp271746p271750.html) still present? Wouldn't a solution be, to make the weak references of one actor dispose as soon as this actor has no strong

Re: A WeakMap where values (not keys) are weak references?

a callback mechanism (i guess the executor is sth. like that.) On 30.03.2017 10:45, T.J. Crowder wrote: Right -- but it's really weak references you're after, right? Because with weak references, a Map can be a WeakValueMap, but other structures are also possible. With that proposal's `executo

Re: A WeakMap where values (not keys) are weak references?

Right -- but it's really weak references you're after, right? Because with weak references, a Map can be a WeakValueMap, but other structures are also possible. With that proposal's `executor` feature, the map can even be proactive removing entries for objects that have become only weakly

Re: A WeakMap where values (not keys) are weak references?

I am also still very interested in Weak references / a weak map, where the values are held weakly. Here is my example: I want to easily build caches, which lose their values, when there are no other references to them. Example pseudo code (assuming server request answers synchronously

Re: A WeakMap where values (not keys) are weak references?

+ > On Mar 20, 2017, at 11:15 PM, /#!/JoePea wrote: > > Hey all, > > I'd like to have something like a WeakMap where the keys can be primitives > and the values are weakly-held Objects, so if there are no more references to > any of the Object values that the entry gets

Re: A WeakMap where values (not keys) are weak references?

ple > times and discussed at quite some length. > > If there isn't an existing document that summarizes the discussions (and > quick searching doesn't find one in the top several hits, though it does > find https://esdiscuss.org/topic/what-is-the-status-of-weak-references at > the very least

Re: A WeakMap where values (not keys) are weak references?

ed at quite some length. > > If there isn't an existing document that summarizes the discussions (and > quick searching doesn't find one in the top several hits, though it does > find https://esdiscuss.org/topic/what-is-the-status-of-weak-refere

Re: A WeakMap where values (not keys) are weak references?

an existing document that summarizes the discussions (and quick searching doesn't find one in the top several hits, though it does find https://esdiscuss.org/topic/what-is-the-status-of-weak-references at the very least), there really should be one... -Boris

Re: A WeakMap where values (not keys) are weak references?

Having java-like weak references would indeed solve many problems and would let us build our own collections. On 21/03/2017 08:34, T.J. Crowder wrote: What are your use cases for it? Rather than tying it to being a `Map`, I'd prefer to see something like Java's [`WeakReference`][1]: You

Re: A WeakMap where values (not keys) are weak references?

What are your use cases for it? Rather than tying it to being a `Map`, I'd prefer to see something like Java's [`WeakReference`][1]: You could store the `WeakReference`s in a `Map` if you wanted strongly-referenced keys with weakly-referenced values. -- T.J. Crowder [1]:

A WeakMap where values (not keys) are weak references?

Hey all, I'd like to have something like a WeakMap where the keys can be primitives and the values are weakly-held Objects, so if there are no more references to any of the Object values that the entry gets removed from the map. For example, it might look like this: ``` { ["foo"] =>

Re: weak references

... how are weak references going to help you with ipc (inter process communication) referencing? On Dec 28, 2016 6:00 AM, <es-discuss-requ...@mozilla.org> wrote: Send es-discuss mailing list submissions to es-discuss@mozilla.org To subscribe or unsubscribe via the World Wide Web,

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On 02/19/2016 01:06 PM, Coroutines wrote: On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. wrote: On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: On 2/19/16 3:50 PM, Coroutines wrote: Side discussion: Why does Javascript have this limitation? -

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. wrote: > On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: >> On 2/19/16 3:50 PM, Coroutines wrote: >>> Side discussion: Why does Javascript have this limitation? - what I >>> view as a limitation?

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: > On 2/19/16 3:50 PM, Coroutines wrote: >> Side discussion: Why does Javascript have this limitation? - what I >> view as a limitation? You'd think this could be supported without >> breaking older JS.. > > I don't see how

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On 2/19/16 3:50 PM, Coroutines wrote: Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS.. I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 4:40 AM, Thomas Foster wrote: > Not sure where you got that idea, but aren't the objects just being converted > to string property names? Huh. I was so certain Node allowed that - I guess I just never made use of it. I knew that 'legally'

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

> Map's API could just go away and follow traditional Object assignment > and existence checks: > > map[key] = value; > > // wish JS had a null-coalescing `?` operator like Coffeescript.. > if (map[key] !== undefined || map[key] !== null) { ... } > > It's totally legal in non-Node JS to have

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:17 AM, Coroutines <corouti...@gmail.com> wrote: > Hi - I hope I am not suggesting something that has been said before ~ > > Having Proxy and eventual Weak References makes it possible to build > Map/WeakMap in plain JS - nothing in hidden

es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

Hi - I hope I am not suggesting something that has been said before ~ Having Proxy and eventual Weak References makes it possible to build Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++). I'd like to propose basing them off of these when Weak References are a 'thing'. Map's API

Re: Weak References

}} const timer = setInterval(function () { setStream(stream, format) }, interval) setStream(stream, format) return stream } ``` In this use case, weak references would simplify the implementation and reduce memory costs. And I would rather take advantage of the GC machinery than

Re: Weak References

let stream = {close() { >> clearInterval(timer) >> timer = stream = null >> }} >> const timer = setInterval(function () { >> setStream(stream, format) >> }, interval) >> setStream(stream, format) >>

Re: memory safety and weak references

At https://esdiscuss.org/topic/memory-safety-and-weak-references#content-1 Dave Herman wrote > Interestingly, I wonder if the idea of only collecting weak references > between turns is immune to such attacks, since it's not possible to > have a bogus reference on the stack between tur

Re: Weak References

s >> garbage collected. >> >> ```js > > [...Somehow reformatted in transit...] > >> >> ``` > > > Hi Isiah, the text in the above code block somehow got reformatted in > transit. You can see the problem at > https://mail.mozilla.org/pipermail/es-discuss

Re: Weak References

> >> My original email featured a use case, although I had to rewrite it to > use > >> explicit garbage collection. I need a way to watch for when the object > is > >> garbage collected. > >> > >> ```js > > > > [...Somehow reformatted in t

Re: Weak References

I also don't get the purpose of this code. What is it trying to achieve? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Weak References

in any local closures because it would end up never being collected - there would always be an active strong reference to it. I don't think a `Reflect.onOnlyOneReferenceLeft(obj, callback)` would make it into the language, so weak references are the best way to avoid this. And if I were doing

Re: Weak References

stream. > > The catch is that I don't want the stream strongly referenced in any local > closures because it would end up never being collected - there would always > be an active strong reference to it. I don't think a > `Reflect.onOnlyOneReferenceLeft(obj, callback)` would make

Re: Weak References

is that I don't want the stream strongly referenced in any >> local closures because it would end up never being collected - there would >> always be an active strong reference to it. I don't think a >> `Reflect.onOnlyOneReferenceLeft(obj, callback)` would make it into the >&

Re: Weak References

s <thomasjamesfos...@bigpond.com> wrote: I haven't had too much of a look at the weak references chatter, but the npm module you linked to provides a callback for when the object is garbage collected. Are you using that feature? Perhaps destructors might be worth thinking about as well alongside

Re: Weak References

[...Somehow reformatted in transit...] > ``` > Hi Isiah, the text in the above code block somehow got reformatted in transit. You can see the problem at https://mail.mozilla.org/pipermail/es-discuss/2015-September/044141.html https://esdiscuss.org/topic/weak-references#content-10 Since the code be

RE: Weak References

I think weak references are discussed before, and get postponed because it can cause information leaks between realms. From: isiahmead...@gmail.com Date: Sat, 5 Sep 2015 07:07:40 -0400 Subject: Weak References To: es-discuss@mozilla.org I'm resurrecting this [1] because I have found a use case

Re: Weak References

he general arguments against gc-driven pre-mortem finalization do not apply. If you just mean some kind of finalization via callback, sure, that's always been part of the strawman. > On Sat, Sep 5, 2015, 09:48 Thomas <thomasjamesfos...@bigpond.com> wrote: > >> I haven

Re: Weak References

That's actually the feature I need... On Sat, Sep 5, 2015, 09:48 Thomas <thomasjamesfos...@bigpond.com> wrote: > I haven't had too much of a look at the weak references chatter, but the > npm module you linked to provides a callback for when the object is garbage > collected

Re: Weak References

On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo <nbdd0...@hotmail.com> wrote: > I think weak references are discussed before, and get postponed because it > can cause information leaks between realms. > http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says To plug th

Weak References

() { clearInterval(timer) timer = stream = null }} const timer = setInterval(function () { setStream(stream, format) }, interval) setStream(stream, format) return stream } ``` In this use case, weak references would simplify the implementation and reduce

Re: Weak References

}} > const timer = setInterval(function () { > setStream(stream, format) > }, interval) > setStream(stream, format) > return stream > } > ``` > > In this use case, weak references would simplify the implementation and > reduce memory c

Re: Weak References

On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows <isiahmead...@gmail.com> wrote: [...] Thankfully, I'm using Node.js, so `weak` [2] is an option (the only option, > really). But I would definitely appreciate if it was available in JS > proper, across engines. V8, SpiderMonkey, and JSC a

Re: memory safety and weak references

This seems to be more a problem with the garbage collector than with weak references. If I understood it correctly, any double value can look like a pointer, and the garbage collector will check what it is pointing at. To me this seems like a source for memory leaks. This problem exists even

Re: memory safety and weak references

There are numerous problems with weak references and primitives, mostly revolving around the ability to regenerate a primitive, e.g. someWeakRef.set(foo) gc() var something = foo someWeakRef.get() // null or foo? vs. someWeakRef.set(foo) var something = foo gc

Re: memory safety and weak references

Marius Gundersen wrote: This seems to be more a problem with the garbage collector than with weak references. If I understood it correctly, any double value can look like a pointer, No, that's not the issue in this (sub-)thread. Oliver was just recollecting thoughts about a position he took

Re: memory safety and weak references

There are numerous problems with weak references and primitives, mostly revolving around the ability to regenerate a primitive, e.g. The issue about non-object WeakMap keys was about semantics only, not implementation safety bugs. If I can put 42 in a WeakMap, it can never be removed, since I

Re: memory safety and weak references

for weak references (observables/events): WeakMaps are useful for membranes too, not just event listeners: http://wiki.ecmascript.org/doku.php?id=harmony:proxiess=proxy#an_identity-preserving_membrane http://wiki.ecmascript.org/doku.php?id=harmony:proxiess=proxy#garbage_collection_behavior

RE: memory safety and weak references

: Re: memory safety and weak references There are numerous problems with weak references and primitives, mostly revolving around the ability to regenerate a primitive, e.g. someWeakRef.set(foo) gc() var something = foo someWeakRef.get() // null or foo? vs. someWeakRef.set

Re: memory safety and weak references

of the weak reference. The WR itself definitely should not affect object liveness. If you mean liveness in terms of like... escape analysis? Then I think you would have no issues as long as the weak reference doesn't escape. Optimization in the presence of weak references is probably not something authors

Re: memory safety and weak references

Hudson, Rick wrote: This brings up another interesting point. Do WeakRefs change a compiler’s liveness analysis? Yes, of course. This could complicate some apparently useful optimizations. { var x = new Something(); someWeakRef.set(x); // Is x dead? (yes) Is x required to contribute

Re: memory safety and weak references

On Mon, Apr 1, 2013 at 2:56 PM, Brendan Eich bren...@mozilla.com wrote: Hudson, Rick wrote: This brings up another interesting point. Do WeakRefs change a compiler’s liveness analysis? Yes, of course. This could complicate some apparently useful optimizations. { var x = new

RE: memory safety and weak references

(); is allowed to return null. - Rick -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Monday, April 01, 2013 5:56 PM To: Hudson, Rick Cc: Oliver Hunt; Marius Gundersen; es-discuss discussion Subject: Re: memory safety and weak references Hudson, Rick wrote

Re: memory safety and weak references

; Marius Gundersen; es-discuss discussion Subject: Re: memory safety and weak references Hudson, Rick wrote: This brings up another interesting point. Do WeakRefs change a compiler's liveness analysis? Yes, of course. This could complicate some apparently useful optimizations. { var

Re: memory safety and weak references

On Apr 1, 2013, at 3:12 PM, Hudson, Rick rick.hud...@intel.com wrote: If the compiler can prove x does not escape the block and it is not used again then it is dead and the compiler is free to reuse the stack slot holding the last reference. So I am arguing that x = null; is not required

RE: memory safety and weak references

: memory safety and weak references On Apr 1, 2013, at 3:12 PM, Hudson, Rick rick.hud...@intel.commailto:rick.hud...@intel.com wrote: If the compiler can prove x does not escape the block and it is not used again then it is dead and the compiler is free to reuse the stack slot holding

Re: memory safety and weak references

to use an optimization. I just wanted to make it clear that one could. -Rick *From:*Oliver Hunt [mailto:oli...@apple.com] *Sent:* Monday, April 01, 2013 6:18 PM *To:* Hudson, Rick *Cc:* Brendan Eich; Marius Gundersen; es-discuss discussion *Subject:* Re: memory safety and weak references On Apr 1

Re: memory safety and weak references

[answering to different messages at once] [cc'ing Oliver Hunt as Apple representative and Luke Hoban as Microsoft representative for questions at the bottom] Le 27/03/2013 23:47, Brendan Eich a écrit : You have it backwards. You are advocating a GC design monoculture (exact rooting only) My

Re: memory safety and weak references

On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote: That said I believe that this does kill any dreams i may have had w.r.t primitive-keyed WeakMaps, kudos to MarkM. Wouldn't a primitive-keyed

Re: memory safety and weak references

On Mar 29, 2013, at 7:36 AM, David Herman dher...@mozilla.com wrote: On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote: That said I believe that this does kill any dreams i may have had w.r.t

Re: memory safety and weak references

On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote: That said I believe that this does kill any dreams i may have had w.r.t primitive-keyed WeakMaps, kudos to MarkM. Wouldn't a primitive-keyed WeakMap just be a strong Map for those keys? And therefore immune to any GC

Re: memory safety and weak references

Le 27/03/2013 01:55, David Herman a écrit : But we need to take this into account as we consider what to do about weak references in ES7. From what I understand, doing exact rooting (instead of conservative stack scanning) solves the problem or more precisely prevents the attack by design

Re: memory safety and weak references

You have it backwards. You are advocating a GC design monoculture (exact rooting only) as an assumption informing a security analysis that must take into account both language features (enumerable weakmaps; weak references) *and* implementation vulnerabilities across a large space of different

Re: memory safety and weak references

On Wed, Mar 27, 2013 at 4:53 PM, David Bruant bruan...@gmail.com wrote: Over the last month after Opera announced moving to WebKit, people on Twitter have been rounds and rounds about Webkits monoculture and how making spec decisions based on specific implementations is a bad thing (if specs

memory safety and weak references

Patrick Walton send me this link to a fascinating approach to exploiting weak references in engines using conservative stack scanning to discover the address of objects: https://github.com/justdionysus/gcwoah I don't fully grok all the details, but IIUC the attacker sprays the heap

Re: memory safety and weak references

Interestingly, I wonder if the idea of only collecting weak references between turns is immune to such attacks, since it's not possible to have a bogus reference on the stack between turns, where there is no stack. Dave On Mar 26, 2013, at 5:55 PM, David Herman dher...@mozilla.com wrote

Re: memory safety and weak references

David Herman wrote: Patrick Walton send me this link to a fascinating approach to exploiting weak references in engines using conservative stack scanning to discover the address of objects: https://github.com/justdionysus/gcwoah I don't fully grok all the details, but IIUC the attacker

Re: memory safety and weak references

Brendan Eich wrote: Dion did the JITSpray paper at BlackHat 2010: This paper is very hard to find now! I downloaded a copy, but I'm not sure about protocol. Breadcrumbs that time out for me are at http://www.woodmann.com/forum/archive/index.php/t-13412.html /be

Re: What is the status of Weak References?

In the weakref case, someone has to keep a strong reference to the listener until it's not needed anymore. The decision to cut this last strong reference is exactly the same decision as deciding when not to re-subscribe. Unless there are multiple references to an object, in which case you cannot

Re: What is the status of Weak References?

David Bruant wrote: There is another approach taken by the requestAnimationFrame API rAF is really not analogous to a listener, it is like setTimeout or setImmediate. See http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0625.html and the whole thread there. /be

Re: What is the status of Weak References?

be used anymore by whoever they shared the proxy with. I feel this is the exact same reflections that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. Real systems such as COM, XPCOM

Re: What is the status of Weak References?

I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications in response to actions by other arbitrary code that has a reference to an object

Re: What is the status of Weak References?

On Sat, Mar 2, 2013 at 6:11 AM, Kevin Gadd kevin.g...@gmail.com wrote: I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications

Re: What is the status of Weak References?

Le 02/03/2013 12:11, Kevin Gadd a écrit : I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications in response to actions by other

Re: What is the status of Weak References?

On 3/2/13 at 3:47 AM, bruan...@gmail.com (David Bruant) wrote: I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. Speaking from ignorance here. One advantage of the resubscribe for every event

Re: What is the status of Weak References?

I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I can't see how this would work in an observer/listener application. The listening object has no way of knowing if it will be deleted when the

Re: What is the status of Weak References?

I'm still balanced on whether/when/how the one-time listener pattern can be effective, but I feel like it's an interesting idea to discuss. Le 02/03/2013 21:13, Marius Gundersen a écrit : I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but

Re: What is the status of Weak References?

Le 03/02/2013 06:21, Brandon Benvie a écrit : Some people would say that garbage collection is the most important advancement in computer science in the last 20 yearshttp://www.codinghorror.com/blog/2009/01/die-you-gravy-sucking-pig-dog.html Don't get me wrong, I didn't say nor didn't mean

Re: What is the status of Weak References?

On Sun, Feb 3, 2013 at 2:58 AM, David Bruant bruan...@gmail.com wrote: Let's see how the example would be with weakrefs: function Storage(){ var storage = [] return { push(e){storage.push(makeWeakRef(e))}, last(){ var last =

Re: What is the status of Weak References?

a reference to the main jQuery object and the rest is attached and the GC has no understanding that you're using only one function of this library. Weakrefs cannot help with this problem. Hopefully, that's real world enough even without the code ;-) There will always be problems that weak references

Re: What is the status of Weak References?

Le 02/02/2013 06:41, Nathan Wall a écrit : David Bruant wrote: David Bruant wrote: Garbage collectors have evolved and cycles aren't an issue any longer, weak references or not. Kevin Gadd wrote: Cycles are absolutely an issue, specifically because JS applications can interact

Re: What is the status of Weak References?

where you're passing a reference to some plug-in/component and want the referred-to object to be eventually collected, we have revocable proxies. Weak references aren't the right tool when you want to express the guarantee that the component can no longer hold onto the object. Cheers, Tom

Re: What is the status of Weak References?

reference around, having passed a weak reference was pointless. For use cases where you're passing a reference to some plug-in/component and want the referred-to object to be eventually collected, we have revocable proxies. Weak references aren't the right tool when you want to express

Re: What is the status of Weak References?

to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. Real systems such as COM, XPCOM, Java, and C# support weak references for good reasons. One cannot do data binding transparently without either making

Re: What is the status of Weak References?

same reflections that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. It is, you don't need to apologize. Real systems such as COM, XPCOM, Java, and C# support weak references

Re: What is the status of Weak References?

and either free it in languages where that's possible or make it collectable in languages with a GC. There will be such cases even in languages where there are weak references. And when such a case will be found, what will be the solution? Adding a new subtler language construct which exposes a bit

Re: What is the status of Weak References?

David Bruant wrote: A view knows own its lifecycle, it involves adding observers in a bunch of places. When the view lifecycle comes to an end for whatever reason, it only makes sense that it removes the observers it added. The problem is that the notification comes from a model object to the

Re: What is the status of Weak References?

that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. It is, you don't need to apologize. Real systems such as COM, XPCOM, Java, and C# support weak references for good

Re: What is the status of Weak References?

Le 31/01/2013 22:48, Kevin Gadd a écrit : I ask this because the lack of weak references (or any suitable substitute mechanism) comes up regularly when dealing with the challenge of porting native apps to JavaScript, and it leads people to consider extremely elaborate workarounds just to build

Re: What is the status of Weak References?

On Fri, Feb 1, 2013 at 2:06 AM, David Bruant bruan...@gmail.com wrote: I don't understand the connection between the lack of weak references and emulating a heap in a typed array. For an algorithm that needs weak references to be correct, the only way to implement that algorithm in JavaScript

Re: What is the status of Weak References?

Le 01/02/2013 12:21, Kevin Gadd a écrit : On Fri, Feb 1, 2013 at 2:06 AM, David Bruant bruan...@gmail.com wrote: I don't understand the connection between the lack of weak references and emulating a heap in a typed array. For an algorithm that needs weak references to be correct, the only way

Re: What is the status of Weak References?

a écrit : It's not possible to polyfill or emulate weak references (or WeakMaps for that matter) in JS without completely disengaging from using the host JS engine's object model. For all practical purposes, you've done such a thing yourself https://github.com/Benvie/**WeakMap https

Re: What is the status of Weak References?

Continuum implements Proxy, this sets up the one case where the two (lack of native WeakMaps and Proxy) to meet. On Fri, Feb 1, 2013 at 10:07 AM, David Bruant bruan...@gmail.com wrote: Le 01/02/2013 15:53, Brandon Benvie a écrit : It's not possible to polyfill or emulate weak references

RE: What is the status of Weak References?

David Bruant wrote: David Bruant wrote: Garbage collectors have evolved and cycles aren't an issue any longer, weak references or not. Kevin Gadd wrote: Cycles are absolutely an issue, specifically because JS applications can interact with systems that are not wholly managed

What is the status of Weak References?

to applications. There's still a strawman up on the wiki: http://wiki.ecmascript.org/doku.php?id=strawman:weak_references and while it appears to be a relatively simple, sane way to expose weak references, it looks like the strawman hasn't been touched since late 2011. Is that because it's dead

Re: What is the status of Weak References?

a general policy against features that allow garbage collection to be visible to applications. There's still a strawman up on the wiki: http://wiki.ecmascript.org/doku.php?id=strawman:weak_references and while it appears to be a relatively simple, sane way to expose weak references, it looks like

Re: What is the status of Weak References?

=strawman:weak_references and while it appears to be a relatively simple, sane way to expose weak references, it looks like the strawman hasn't been touched since late 2011. Is that because it's dead? Or was it deprioritized because weak references are believed to not be needed by JS application developers? I

Re: What is the status of Weak References?

that it is designed to be a secure/sandboxed language - I always was under the impression that for such uses you would need a layer like Caja. Postponing work on Weak References due to an information leak feels to me like prioritizing theoretical security concerns over the real usability/implementation

Re: What is the status of Weak References?

a general policy against features that allow garbage collection to be visible to applications. There's still a strawman up on the wiki: http://wiki.ecmascript.org/doku.php?id=strawman:weak_references and while it appears to be a relatively simple, sane way to expose weak references, it looks like

Re: What is the status of Weak References?

and while it appears to be a relatively simple, sane way to expose weak references, it looks like the strawman hasn't been touched since late 2011. Is that because it's dead? Or was it deprioritized because weak references are believed to not be needed by JS application developers? I believe

Re: What is the status of Weak References?

to be a relatively simple, sane way to expose weak references, it looks like the strawman hasn't been touched since late 2011. Is that because it's dead? Or was it deprioritized because weak references are believed to not be needed by JS application developers? I believe that proposal

Re: Weak references and destructors

On 2009-12-12, at 18:14, Mark S. Miller wrote: In my experience, it is always a bad idea for the GC to invoke user-code. Always? E uses async post mortem finalization to implement distributed acyclic GC. Without some way for GC to invoke user code, I don't see how this is possible.

  1   2   >