WeakMap not the weak needed for zombie views
Hi, I've been reading about WeakMap in the draft. To my surprise, it is not at all what I thought it would be or what I was hoping to use. At least that is my understanding. My use case is in MV* architectures. With current MV* frameworks, a model holds strong references to the views observing that model. If a view is removed from the DOM, all other references in the application are lost to that view, but the view never stopped observing the model object, that strong reference from model to view results in a zombie view. Avoiding this means views need to have `destroy` methods that unsubscribes the view from the model. It is easy for the application programmer to forget to call a view's `destroy` method and the application leaks memory. As a result of the leak, the user experience and ultimately the reputation of the Web suffers. If a model could hold weak references to its observers, this would safeguard against accidental and inevitable application programmer forgetfulness. It appears that WeakMap cannot help solve the current MV* zombie view problem. Or did I miss something? I was expecting WeakMap to hold its values weakly and set them to undefined or delete the associated key when the value was garbage collected. Does anything exist or is coming to help solve the zombie problem? Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds its keys weakly. The difference compared with the ECMAScript WeakMap is that instances of WeakIdentityKeyDictionary have an iterator so the observers can be stored as the keys and still discoverable without keeping other strong references. The ECMAScript standard specifically disallows in iterator. Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Trailing comma for function arguments and call parameters
On Fri, Jul 4, 2014 at 9:33 AM, Oliver Hunt wrote:
>
> On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov
> wrote:
>
> > Hi,
> >
> > Will it makes sense to standardize a trailing comma for function
> arguments, and call parameters?
> >
> > We have it for Array and Object initialisers, and people like using them
> for long lists with prediction of new items adding in the future:
> >
> > ```
> > var modes = [
> > read,
> > write,
> > ];
> >
> > var platforms = {
> > web,
> > canvas,
> > };
> > ```
>
> I suspect, but brendan could tell us otherwise, that the allowance of
> trailing commas is a result of a bug in the _early_ _early_ days of JS,
> which then got matched by the wonders of bug for bug compat, and so became
> necessary for web compatibility.
>
>
Yeah, as mentioned, it for a long time was considered as a bad practice
because of inconsistency of implementations, and I have suspicions that
this perception of "early design mistake" was dictated by exactly those
inconsistencies, that made the feature useless and harmful. However, times
have changed: with a build/transform step the feature is turned into a very
useful one, and can safely be used across implementations, and e.g. in our
code base is a de-facto standard (you'll have a lint warning if you forget
the trailing comma -- by the described above reasons: better git blame, and
convenience of future items adding).
> Also, i’m not sure that your intended uses is sufficiently compelling to
> justify non-backwards compatible syntax (i’m not against adding new syntax,
> i just feel that it needs to have substantial benefits)
>
> Hence, i don’t think this should be extended to other constructs.
>
>
At the same time, yes, I completely agree, that for the language itself,
it's probably not good enough reason to extend the syntax. And still, for
the language itself, globally, we'll still have inconsistency of trailing
comma handling in legacy IE engines. So, yes, I think it's just better to
implement as a local extension if will be needed just yet. Just wanted to
bring it at least to double-check and clarify/confirm.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Loader.parse ?
In https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instantiatesucceeded-instantiateresult-functions , 15.2.4.5.3 InstantiateSucceeded(instantiateResult) Functions The step number 4 reads: - If instantiateResult is undefined, then Let body be the result of parsing load.[[Source]], interpreted as UTF-16 encoded Unicode text as described in 10.1.1, using Module as the goal symbol. Throw a SyntaxError exception if the parse fails or if any static semantics errors are detected. Set load.[[Body]] to body. Set load.[[Kind]] to declarative. Let depsList be the ModuleRequests of body. While trying to use es6-module-loader, https://github.com/ModuleLoader/es6-module-loader/, as the Loader in Traceur, https://github.com/google/traceur-compiler/, rather than our current TraceurLoader, it became clear that the above step 4 would be architecturally clearer if it were a hook comparable to normalize/locate/fetch... For example: parse(load) -> depsList nicely fulfills the requirements of step 4. The loader.js file in https://github.com/ModuleLoader/es6-module-loader/pull/174 shows the consequences in source that follows the spec. Adding `parse` as a Loader hook allows customization of the declarative path of the Loader. This mechanism is a good fit for Traceur, providing evidence that this API would prove useful. Please consider adding a `parse()` hook to the Loader. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
