On Sep 2, 2010, at 4:08 AM, Erik Corry wrote:
> 2010/9/2 Leo Meyerovich <lmeyerov at gmail.com>:
>> There are use cases for enumeration like proper native GC in data flow abstractions
>> Perhaps you could elaborate on this. I wasn't able to understand what
> you meant by this.
>
I mean a natural embedding of data flow constructs as in http://www.cs.brown.edu/~greg/thesis.pdf that eliminate many instances of spaghetti/non-composable callback graphs and replaces them with direct/linear/composable/self-managing code while co-existing with the rest of the language.
There's a lot of debatable language philosophy in the that thesis, but distractions aside, it's essentially an expressive continuation of data binding we're already seeing in many modern systems (e.g., Flex, LINQ, Max/MSP have weaker forms.). Even if you don't directly use such a language or library, you can view them as forming a basic pattern. This pattern comes up repeatedly, especially in the AJAX community: while I've worked on one such JS system, I've seen it repeatedly rediscovered/reinvented by others without any prior knowledge of it. This pattern is also used outside of the web community.
> Btw. In case it isn't obvious I would rather avoid changes to the
> WeakMaps proposal that make the effects of GC visible to the
> programmer (beyond the obvious one of the program not crashing with an
> OOM error). This is bound to lead to incompatibilities and/or
> unwanted restrictions on the implementation of GC. Making the keys
> enumerable would be one such change.
The challenge is that the pattern, wrt proper GC, is to enumerate over a weak collection (e.g., map) of callbacks, firing them and then repeating the process for anything registered to those callbacks. If the end of a callback chain is used, the chain won't be collected. If the end of a chain of such propagation isn't used, the chain (back to the last used link) can be collected. Not doing so means a (significant) memory leak and likely performance loss.
This collection semantics can be encoded... but at that point we're likely 1) reimplementing garbage collection within JS and 2) forcing manual memory management by the programmer. A similar argument can be made about not really needing weak maps for membranes -- manual management could work, but it's a headache (and I suspect breaks modularity in the same sense as not having GC in general would).
Hope that made sense and I'm looking forward to any other use cases.
Regards,
- Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100902/351a1a67/attachment.html>