On Sep 2, 2010, at 4:08 AM, Erik Corry wrote:
> 2010/9/2 Leo Meyerovich <lmeye...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
