Path: csiph.com!aioe.org!news.mb-net.net!open-news-network.org!.POSTED.35.233.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Recording changes to an object Date: Thu, 05 Jul 2018 00:32:44 +0200 Organization: PointedEars Software (PES) Lines: 66 Message-ID: <4080171.LvFx2qVVIh@PointedEars.de> References: <1620852.VI2in3QvqR@PointedEars.de> <1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="35.233.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch:178.197.233.35"; logging-data="32437"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.2 X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Thomas 'PointedEars' Lahn wrote: >> There should be a *built-in* Object.clone() or Object.prototype.clone() >> method that does this, but unfortunately there is not yet. So user >> libraries have to come to the rescue. > > The issue here though is that an object is not simple a set of properties > and methods. There is potentially, and probably, an associated state which > is unobservable from outside the object (due to encapsulation). Possible. But that would not be a major problem: an object with special requirements could implement a clone() method method that is called by Object.clone() when it the object is about to be cloned: Object.clone = ((orig) => { if (orig.clone instanceof Function) return orig.clone(); /* standard cloning */ }); Compare JSON.stringify() which calls the toJSON() method of an object to be stringified if it has one. > As such, Object.prototype.clone() is required instead of Object.clone(), > otherwise you're simply making an "observable clone". How did you get that idea? Object.prototype.clone() would just be syntactic sugar: const CLONE = obj.clone(); instead of const CLONE = Object.clone(obj); There is at least one other language that has a “clone” operator. In ES it could be: const CLONE = clone obj; For backwards compatibility it appears to be the best idea to have a native Object.clone(). Then name-safe polyfills can be provided, and the user has the freedom to override Object.prototype.clone() or override/define the clone() method of the target object or its other prototype. Once/if backwards compatibility is not a concern (e.g. if it is Babel’d away), the “clone” operator could be used instead. > Even so, the semantics of JavaScript would have to change as well in my > estimation to support this more naturally. Specifically in regards to > equality, the "new" operator, generators, and probably more. I do not think so. > Non trivial, but somewhat related is the recent research paper you might > have seen: > > Thanks, I will read it later. -- PointedEars FAQ: | | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.