More tooling is great for developing new software in ES, but it does
nothing to address use cases where existing software and algorithms can't
be ported without Weak References. Perhaps enough research will allow us to
arrive at some sort of general 'best practice' for replacing the use of
weak references with something else; sounds like something some people with
PhDs could write a paper on :)


On Fri, Nov 8, 2013 at 8:57 AM, David Bruant <[email protected]> wrote:

> Le 08/11/2013 17:09, Jason Orendorff a écrit :
>
>  (As a bonus, the weirdness will happen in one implementation and not
>> another, and you and your users will blame the implementation. So
>> there will be pressure on implementers to reduce the nondeterminism by
>> doing GC more frequently—which trades off against other performance
>> measures.)
>>
> Super-bonus: Heisenbugs (bugs that happen in prod, but not while debugging)
> https://en.wikipedia.org/wiki/Heisenbug
>
>
>  And in this case, it all seems unnecessary. There is apparently
>> already explicit code for both removing B and C, and later coping with
>> their disappearance (since the weak reference may go null). That code
>> could just as easily set a bit on B and C marking them as removed, and
>> then test that in the chasing code.
>>
> Agreed. In a way, Kevin conceded it when he wrote in an earlier message:
>
>  I had to manually remove the event listeners at an appropriate time (and
>> finding an appropriate time can be difficult!)
>>
> And this looks very much like a software engineering issue, not a language
> issue. Maybe we (JavaScript developers!) should invest in better memory
> tooling see how far it gets us. We have fantastic tooling for studying time
> perf (Chrome has 2 types of profilers and the timeline view to help with
> the 60fps, Firefox and IE11 getting there too), how come we're still doing
> low-level heap snapshots for memory perf? Is space fundamentally that much
> harder to study than time?
>
> Taking the tooling road first, worst case, we throw the tooling away...
> not an option when a feature is in the wild.
>
> Let's try at least?
>
> David
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to