Idea: Reflect.hasExternalReference

T.J. Crowder tj.crowder at farsightsoftware.com
Sun Jan 15 14:26:32 UTC 2017


I think the point is that immutability syntax would apply to the use case
you've described, because if the object passed is immutable, it doesn't
matter whether the sender has a reference to it or not. The receiver can
use it without caring, and without making a defensive copy, since it's
immutable.

-- T.J.

On Sun, Jan 15, 2017 at 2:20 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> I am not following. The object is immutable from their side, because
> they'll never be able to even access it since it's not referenced.
>
> New syntax wouldn't solve anything I've talked about.
>
> Have I misunderstood you?
>
> On Sun, Jan 15, 2017 at 12:51 PM, Alexander Jones <alex at weej.com> wrote:
>
>> IMO we should explore generalising syntax for map literals and object
>> destructuring, bringing something like Immutable.Map into the spec, and
>> thus bringing JS into a new modern era.
>>
>> Otherwise people who care about this stuff will just continue to move to
>> other languages like ClojureScript in order to get the expressivity and
>> safety they want!
>>
>> On Sun, 15 Jan 2017 at 10:34, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> I am not sure how feasible this concept is, and I'll start just with the
>>> pattern it's useful for.
>>>
>>> ```js
>>> someRef.setup({
>>>   one: 'or more',
>>>   runtime: 'definition'
>>> });
>>> ```
>>> In JS user-land, the amount of unnecessary duplicated objects is
>>> embarrassing.
>>>
>>> We all know that immutability is great and we all know that functions
>>> should never mutate received arguments, but there is absolutely zero side
>>> effect in modifying, changing, erasing, you name it, an object passed like
>>> the one in that `.setup({...})`
>>>
>>> As of today, basically every method used to setup one-off objects will
>>> use one of the following techniques:
>>>
>>>   * a shallow copy via `Object.create(Object.getPrototypeOf(options),
>>> Object.getOwnPropertyDescriptors(options))`
>>>   * an enumerable only copy via `Object.assign({}, options)`, probably
>>> more common but yet, most of the time, practically unnecesary
>>>
>>> Things become even more difficult to improve when it comes to simply
>>> chaining objects together, where it's not possible to simply define the
>>> prototype of the received object, throwing away a performance boost
>>> possibility like the one Netfilx recently had [1]
>>>
>>> Shortcutting and destructuring also makes the usage of one-off literals
>>> great, and states are the most basic, yet common, example.
>>>
>>> ```js
>>> component.setState({
>>>   label,
>>>   user,
>>>   time: Date.now()
>>> });
>>> ```
>>>
>>> ## Back to the Reflect.hasExternalReference idea
>>>
>>> Within the hypothetical `.setState(...)` method, invoking
>>> `Reflect.hasExternalReference` would return `true` it the object was passed
>>> as literal, without any possible external reference.
>>>
>>> ```js
>>> class Component {
>>>   setState(state) {
>>>     this.state = Reflect.hasExternalReference(state) ?
>>>       Object.assign({}, this.state, state) :
>>>       Object.setPrototypeOf(state, this.state);
>>>     // update only differences
>>>     this.render(Object.keys(state));
>>>   }
>>> }
>>> ```
>>> If there was a way to know passed literals, I am sure a lot of software
>>> could automatically boost performance:
>>>
>>>   * less polluted GC
>>>   * more recycled one-off objects
>>>   * less need to copy/clone over and over one-off literals that couldn't
>>> be mutate anywhere else anyway
>>>
>>> What do you think? Does any of this make sense?
>>>
>>> Best Regards
>>>
>>>
>>>
>>>
>>> [1] http://techblog.netflix.com/2017/01/crafting-high-perfor
>>> mance-tv-user.html
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> es-discuss mailing list
>>>
>>> es-discuss at mozilla.org
>>>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170115/92fb491b/attachment-0001.html>


More information about the es-discuss mailing list