d at domenic.me (2015-09-15T21:20:26.281Z)
On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows <isiahmeadows at 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 all have weak references
> to JS objects as part of their public API, and I would be surprised if the
> implementation work would be anything significant.
[2]: https://github.com/TooTallNate/node-weak
I just skimmed it and it recapitulates the most common mistake that people
make when first approaching this issue: pre-mortem finalization, like
java.lang.Object.finalize(). This jumped out at me as soon as I saw
`Boolean weak.isNearDeath(Weakref ref)` on that page. The key constraint
of post-mortem finalization is that execution can only ever reach
non-condemned, i.e., normally reachable, objects.
Separately, for reasons of discouraging the hazardous pattern of separating
the testing and fetching that I criticized in your code, no the test-only
methods should be present in the API (isDead, isNearDeath). I don't see a
reason for a isWeakRef -- is there any reason for a wrapper around a weak
reference not to be able to emulate a weak reference? There may be -- I am
generally sympathetic to such integrity checks when some guarantee follows
from the check. Is there such a guarantee in this case?
And finally of course, the whole callback approach is wrong. However, it
does make me wonder about whether the strawman's callback API is now
inappropriate as well. In the new post-promise world, perhaps a better API
is simply to provide a query that returns one promise-for-undefined that
becomes fulfilled only when the weak reference has been nulled. OTOH, this
would prevent the economy of the ParcPlaceSmalltalk amortized weak-array
approach. An interesting question.d at domenic.me (2015-09-15T21:20:19.835Z)
On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows <isiahmeadows at 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 all have weak references
> to JS objects as part of their public API, and I would be surprised if the
> implementation work would be anything significant.
[2]: https://github.com/TooTallNate/node-weak
I just skimmed it and it recapitulates the most common mistake that people
make when first approaching this issue: pre-mortem finalization, like
java.lang.Object.finalize(). This jumped out at me as soon as I saw
`Boolean weak.isNearDeath(Weakref ref)` on that page. The key constraint
of post-mortem finalization is that execution can only ever reach
non-condemned, i.e., normally reachable, objects.
Separately, for reasons of discouraging the hazardous pattern of separating
the testing and fetching that I criticized in your code, no the test-only
methods should be present in the API (isDead, isNearDeath). I don't see a
reason for a isWeakRef -- is there any reason for a wrapper around a weak
reference not to be able to emulate a weak reference? There may be -- I am
generally sympathetic to such integrity checks when some guarantee follows
from the check. Is there such a guarantee in this case?
And finally of course, the whole callback approach is wrong. However, it
does make me wonder about whether the strawman's callback API is now
inappropriate as well. In the new post-promise world, perhaps a better API
is simply to provide a query that returns one promise-for-undefined that
becomes fulfilled only when the weak reference has been nulled. OTOH, this
would prevent the economy of the ParcPlaceSmalltalk amortized weak-array
approach. An interesting question.
On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows <isiahmeadows at 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 all have weak references > to JS objects as part of their public API, and I would be surprised if the > implementation work would be anything significant. > [...] > > [2]: https://github.com/TooTallNate/node-weak > I just skimmed it and it recapitulates the most common mistake that people make when first approaching this issue: pre-mortem finalization, like java.lang.Object.finalize(). This jumped out at me as soon as I saw Boolean weak.isNearDeath(Weakref ref)on that page. The key constraint of post-mortem finalization is that execution can only ever reach non-condemned, i.e., normally reachable, objects. Separately, for reasons of discouraging the hazardous pattern of separating the testing and fetching that I criticized in your code, no the test-only methods should be present in the API (isDead, isNearDeath). I don't see a reason for a isWeakRef -- is there any reason for a wrapper around a weak reference not to be able to emulate a weak reference? There may be -- I am generally sympathetic to such integrity checks when some guarantee follows from the check. Is there such a guarantee in this case? And finally of course, the whole callback approach is wrong. However, it does make me wonder about whether the strawman's callback API is now inappropriate as well. In the new post-promise world, perhaps a better API is simply to provide a query that returns one promise-for-undefined that becomes fulfilled only when the weak reference has been nulled. OTOH, this would prevent the economy of the ParcPlaceSmalltalk amortized weak-array approach. An interesting question. -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150905/6e4099ea/attachment.html>