On 23 February 2015 at 10:37, David Bruant <bruant.d at gmail.com> wrote:

> Le 23/02/2015 10:10, Michał Wadas a écrit :
>
>> Cloning objects is long requested feature.
>> "clone object javascript" yields 1 480 000 results in Google.
>>
> I'd like to share this as an answer
> http://facebook.github.io/immutable-js/#the-case-for-immutability
> "If an object is immutable, it can be "copied" simply by making another
> reference to it instead of copying the entire object. Because a reference
> is much smaller than the object itself, this results in memory savings and
> a potential boost in execution speed for programs which rely on copies
> (such as an undo-stack)."
>
> ```js
> var map1 = Immutable.Map({a:1, b:2, c:3});
> var clone = map1;
> ```
>

To be clear, that is only true in general as long as immutable objects also
don't have identity. With identity (i.e., reference equality), the
difference between an alias and an actual copy is still observable.
JavaScript is plagued by all objects having identity, a well-known problem
preventing various optimisations in compilers.

In other words, the ES spec would have to make an explicit and conscious
decisions to say that "cloning" an immutable object is not actually cloning
it. A compiler or runtime system usually cannot apply that decision itself
(except for primitives, which have structural equality).

Despite people *saying* all over the Internet they want cloning, maybe they
> want immutability?


Yeah, I tend to agree with that sentiment.

/Andreas


My proposition is to create a new well known Symbol - Symbol.clone and
>> corresponding method on Object - Object.clone.
>>
>> Default behavior for an object is to throw on clone try.
>> Object.prototype[Symbol.clone] = () => { throw TypeError; }
>> Users are encorauged to define their own Symbol.clone logic.
>>
>> Primitives are cloned easily.
>> Number.prototype[Symbol.clone] = String.prototype[Symbol.clone] =
>> Boolean.prototype[Symbol.clone] = function() {return this.valueOf();}
>>
> Primitives are immutable, no need to clone them.
> If you're referring to "primitive objects", it might be better to forget
> about this weird corner of the language than polish it.
>
> Back to something you wrote above:
>
>> Users are encorauged to define their own Symbol.clone logic.
>>
> Perhaps this cloning protocol can be purely implemented in userland as a
> library and doesn't need support from the language. That's one of the
> reasons symbols have been introduced after all.
>
> David
>
> _______________________________________________
> 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/20150223/63b08eb7/attachment.html>

On 23 February 2015 at 10:37, David Bruant <bruant.d at gmail.com> wrote:

> Le 23/02/2015 10:10, Michał Wadas a écrit :
>
>> Cloning objects is long requested feature.
>> "clone object javascript" yields 1 480 000 results in Google.
>>
> I'd like to share this as an answer
> http://facebook.github.io/immutable-js/#the-case-for-immutability
> "If an object is immutable, it can be "copied" simply by making another
> reference to it instead of copying the entire object. Because a reference
> is much smaller than the object itself, this results in memory savings and
> a potential boost in execution speed for programs which rely on copies
> (such as an undo-stack)."
>
> ```js
> var map1 = Immutable.Map({a:1, b:2, c:3});
> var clone = map1;
> ```
>

To be clear, that is only true in general as long as immutable objects also
don't have identity. With identity (i.e., reference equality), the
difference between an alias and an actual copy is still observable.
JavaScript is plagued by all objects having identity, a well-known problem
preventing various optimisations in compilers.

In other words, the ES spec would have to make an explicit and conscious
decisions to say that "cloning" an immutable object is not actually cloning
it. A compiler or runtime system usually cannot apply that decision itself
(except for primitives, which have structural equality).

> Despite people *saying* all over the Internet they want cloning, maybe they
> want immutability?


Yeah, I tend to agree with that sentiment.