Static `super` may cause a unwanted "memory leak".

[/#!/JoePea]

Suppose someone reads about the awesome object-initializer short hand, and
writes some code like this:

```js
// How do we create dynamically named functions who's name is guaranteed?
Like this:

let dynamicMethodName = "someMethod"
let tmp = {
    [dynamicMethodName]() {
        // ...
    }
}

let f = tmp[dynamicMethodName]

f.name // someMethod
```

Little does the unsuspecting author know that the `tmp` object will be
stored as the `HomeObject` of the created function, therefore it may be
considered that some memory has leaked. Suppose an author makes a function
factory using that technique,

```js
export default
function SomeFactory(name) {
  let tmp = {
    [name]() { /* this doesn't use `super` */ }
  }
  return tmp[name]
}
```

Then that will store each new `tmp` object in memory although the user of
the factory only cares about the functions created.

If `super` were dynamic, `tmp` would be GCable after it is no longer used
in that example, and the object-initializer shorthand method could be
treated just the same as any other function as opposed to a special
"concise method" (where currently, to me, "concise method" simply means
"function that uses static `super`, otherwise there's no practical
difference).

I believe that the object-initializer method shorthand should be syntax
sugar, nothing more, so that the following is as equivalent as possible
(the only difference being that the function referenced in the following
example doesn't have an assigned `.name` in all JS engines, although Chrome
does assign it nowadays):

```js
let dynamicMethodName = "someMethod"
let tmp = {
    [dynamicMethodName]: function () {
        // ...
    }
}

let f = tmp[dynamicMethodName]

f.name // sometimes undefined, "someMethod" in Chrome 51.
```


*/#!/*JoePea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160802/a6270913/attachment.html>