Le 27/03/2013 00:22, Kevin Gadd a écrit :
OK, it seems like Weak References are now being discussed without the
context of previous discussions of weak references, which is a little
annoying. Non-contrived real-world use cases that require Weak
References (or a primitive with similar capabilities, like a Map with
weak values instead of weak keys, I'm not picky) have already been
provided *on this list* the last time WRs were discussed. I provided
two based on real applications I've worked on; I thought other people
in the discussion thread provided more.
I've been through the thread and I haven't read any use case that
*requires* Weak References. Only use cases where they make life easier
to various degrees. It's been agreed that in most cases, adding an
explicit .dispose() or equivalent protocol could work too.
The only use case where I have some intuition of WeakRefs making a
significant difference is the data binding use case. I find the "compile
weakrefs from another language" use case a bit too early since compiling
to JS is such a recent trend.
As I said in one message, there is always a need of cutting some
reference somewhere [1] for WeakRefs to work.
What process needs to be followed before people will believe that Weak
References are a real primitive that solves real problems? Do you need
a set of broken, non-functional 'real world' applications written in
JS that work in a customized version of V8/SpiderMonkey that has WRs?
Do you need more verbose descriptions of use cases than previously
provided? I can try to provide more justification than I did
previously if this is necessary; I wasn't aware that it was.
From what I read, until Jason joined the discussion, it was mostly me
that was being annoying on use cases. So I can give my criteria if that
helps (as a reminder, I'm not part of TC39, so you're also free to
ignore what I say).
I'd like to see the description of a use case (something more specific
than just "data binding") and an implementation that has been thought
with memory management in mind. If this implementation proves to be
minimalistic and simple enough, but yet too complex to use without
WeakRefs, I'll be convinced.
The "thought with memory management in mind" part is important. I don't
think I have ever seen a talk describing a library where the author
talked about the lifecycle of the objects created/used by the library.
Memory footprint is sometimes discussed, but not lifecycle. From what
I've observed, it's only after a severe memory leak is observed that
people start to think about object lifecycle. Obviously, at that time,
it's sometimes too late to do major refactoring and a lot of people
would love to have weakrefs as a quickfix tool.
From what I've observed too, very few people seem to understand GC at
all. A lot of people still cite "cycles" as an issue of GC. So I wonder
how many people really think of object lifecycles properly when
designing libraries/frameworks.
But what if object lifecycle was considered in the design? Maybe we'd
realize WeakRefs are necessary to dramatically reduce the
burden/boilerplate of some use cases. Maybe we'd find out a different
way of designing libraries and realize WeakRefs aren't that necessary
after all.
Maybe tomorrow, i'll be writing a library and see the light or see the
design of a library and see the light that without weakrefs, life is so
much harder. I haven't yet come across such a case, so I'm not convinced
yet.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/028935.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
