Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35260 > unrolled thread

Recording changes to an object

Back to article view | Back to comp.lang.javascript

Contents

  Recording changes to an object Andrew Poulos <ap_prog@hotmail.com> - 2018-06-21 15:54 +1000
    Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 01:47 -0700
    Re: Recording changes to an object Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-06-21 17:01 +0100
      Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 09:48 -0700
        Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-22 09:58 +0100
    Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-21 21:03 +0200
      Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 16:25 -0700
      Re: Recording changes to an object Andrew Poulos <ap_prog@hotmail.com> - 2018-06-22 09:34 +1000
        Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 17:02 -0700
          Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 18:03 -0700
          Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-22 10:06 +0100
            Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-22 02:21 -0700
              Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-22 18:31 +0100
                Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-22 20:16 -0700
        Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-22 02:23 +0200
          Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 17:31 -0700
        Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-22 02:55 +0200
          Re: Recording changes to an object Andrew Poulos <ap_prog@hotmail.com> - 2018-06-22 12:37 +1000
            Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-22 02:23 -0700
              Re: Recording changes to an object Jake Jarvis <pig_in_shoes@yahoo.com> - 2018-06-22 14:35 +0200
                Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-22 05:57 -0700
                  Re: Recording changes to an object Mickey Finn <mfinn@gmail.com> - 2018-06-22 15:43 -0300
                Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-22 13:51 +0200
                  Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-22 06:04 -0700
                  Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-22 18:33 +0100
                    Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-24 14:36 +0200
                      Re: Recording changes to an object "Mark-" <nospam@mapson.xyz> - 2018-06-24 13:56 +0000
                      Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-25 10:06 +0100
                        Re: Recording changes to an object Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-06-25 02:40 -0700
                          Re: Recording changes to an object Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-06-25 02:47 -0700
                            Re: Recording changes to an object Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-06-25 02:51 -0700
                              Re: Recording changes to an object Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-06-25 02:54 -0700
                                Re: Recording changes to an object Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-06-25 02:58 -0700
                      Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-25 19:26 +0100
                        Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-30 19:47 +0200
                          Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-01 10:56 +0100
              Re: Recording changes to an object Andrew Poulos <ap_prog@hotmail.com> - 2018-06-23 17:19 +1000
                Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-23 00:51 -0700
                  Re: Recording changes to an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-06-23 11:27 +0100
                  Re: Recording changes to an object Andrew Poulos <ap_prog@hotmail.com> - 2018-06-23 20:59 +1000
                    Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-23 05:51 -0700
      Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-30 19:43 +0200
        Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-01 15:22 +0200
          Re: Recording changes to an object Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-07-02 16:29 +0200
            Cloning an object (was: Recording changes to an object) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-04 23:25 +0200
              Re: Cloning an object Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-07-05 10:00 +0200
                Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 19:49 +0200
                  Re: Cloning an object Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-07-05 20:37 +0200
                    Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 23:35 +0200
                      Re: Cloning an object Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-07-05 23:54 +0200
                        Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-06 00:32 +0200
                    Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-06 00:24 +0200
                      Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-06 18:48 +0100
                        Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-06 23:51 +0200
                          Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-07 15:51 +0100
                            Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-07 08:39 -0700
                              Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-09 10:20 +0100
                                Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-09 02:35 -0700
                                Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-09 02:41 -0700
                            Re: Cloning an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-08 12:20 +0200
                          Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-08 14:38 +0100
                            Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-08 13:10 -0700
                              Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-09 09:48 +0100
                                Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-09 02:28 -0700
                                  Re: Cloning an object Julio Di Egidio <julio@diegidio.name> - 2018-07-09 02:38 -0700
                              Re: Cloning an object John G Harris <niam@jghnorth.org.uk.invalid> - 2018-07-09 19:11 +0100
        Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-02 21:01 -0700
          Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 00:32 +0200
            Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-04 19:23 -0700
              Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 06:38 +0200
                Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-04 23:21 -0700
                  Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 09:25 +0200
                    Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-05 07:44 -0700
                      Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-05 19:35 +0200
                        Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-06 12:59 -0700
                          Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-06 23:22 +0200
                            Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-07 12:45 -0700
                              Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-08 11:13 +0200
                                Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-07-08 05:03 -0700
                                  Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-08 13:42 -0700
                                    Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-07-08 13:46 -0700
                                Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-08 13:41 -0700
                                  Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-09 00:35 +0200
                                    Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-10 01:03 -0700
                                      Re: Recording changes to an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-10 20:50 +0200
                                        Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-07-10 16:09 -0700
    Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-06-21 15:09 -0700
      Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 16:30 -0700
        Re: Recording changes to an object "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-06-21 16:57 -0700
          Re: Recording changes to an object Julio Di Egidio <julio@diegidio.name> - 2018-06-21 17:01 -0700

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#35400

On Sunday, 8 July 2018 22:42:53 UTC+2, Michael Haufe (TNO)  wrote:

> Adults are talking. Go drink your juice.

LOL, you bunch of vile morons and even retarded at that...

You go fuck yourself, and your bullshit.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#35397

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > *built-in* does not automatically imply black-magic access to the
> > internal state of the object
> 
> Yes it does.

Insufficient. Show evidence to justify. I agree it COULD do so, that doesn't imply automatically that it does.

> > #1 - Object.clone(obj) where obj.clone !== undefined #2 -
> > Object.clone(obj) where obj.clone === undefined
> > 
> > in case #1: why not just call obj.clone() ?
> 
> That is what I said: syntactic sugar.

"Syntactic sugar causes cancer of the semicolon." [1]

This is redundant at best.

> > in case #2: You're limited to an observable clone of public members
> > unless you're using black magic behind the scenes to violate
> > encapsulation.
> 
> Nonsense.

If obj.clone === undefined , you don't have a choice do you? Either the default implementation of your static method clones the public members, or it uses black-magic to access the internal state to clone. You don't get a 3rd choice with how you've defined this.

> > If all objects are clonable in some way by default, why not just have
> > Object.prototype.clone() ? I still don't see what the static version
> > gives you.
> 
> Formerly, easier for-in iteration.

Which doesn't seem relevant if you're using some unspecified built-in mechanism anyway in it's implementation for Case #2 above

> Since ECMAScript Ed. 5: An object does
> not have to have the object referred to by Object.prototype in its prototype
> chain to be cloneable.

Is it possible to not be cloneable even with a null prototype? Any concept of singleton? If your *built-in* static method has privileged access, then what?

This also raises again my referenced issue of substitution:

Object.clone(obj) instanceof obj ?

> > .toJSON() is a bad comparison
> 
> Wrong, as it follows the same approach: The caller implements the method if
> they want object-specific behavior.

Still a bad comparison. It's only vaguely comparable because it follows the idiocy of ascribing meaning to an operation extrinsic to the owning object. obj.toJSON() doesn't even return JSON...

> > and a wart on the language
> 
> Nonsense.

#0 - The method names are terrible. "stringify"? really?
#1 - obj.toJSON() doesn't return JSON
#2 - It's not functional due to .toJSON() requirement on target
#3 - Neither is it OO due to static call against another object
#4 - The schema is dictated dictated extrinsically
#5 - It can not evolve by definition
#5a - Bugs are permanent
#6 - It can not encode cyclical structures or represent references
#6a - unless you encoded another DSL within its structure (see #4)
#7 - The spec is wack:
    <https://esdiscuss.org/topic/json-parser-grammar#content-5>
#8 - The semantics of serialization are spread between the target and the static method (#2, #3)

> > (dictated by Crockford's initial implementation)
> 
> Cite evidence.

<http://www.ietf.org/rfc/rfc4627.txt>
<https://mail.mozilla.org/pipermail/es-discuss/2009-June/009445.html>
<https://ecma-international.org/ecma-262/5.1/#sec-15.12>

> > The problem with JSON.stringify() and your Object.clone() is that you
> > throw away subtype polymorphism with it.
> 
> Nonsense.

Prove it.

Look, I'm all for adding a cloning facility to the language. Since you seem to have the energy and time, write up a proper proposal and submit it to the committee. It would also resolve any remaining confusion here on the semantics. I'm hoping you've already read the history of this feature[2]. Turn this into something more than mental masturbation.

[1] <http://www.cs.yale.edu/homes/perlis-alan/quotes.html>
[2] <https://esdiscuss.org/topic/object-clone-not-quite-a-proposal#content-4>

[toc] | [prev] | [next] | [standalone]

#35405

Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>>> *built-in* does not automatically imply black-magic access to the 
>>> internal state of the object
>> 
>> Yes it does.
> 
> Insufficient. Show evidence to justify. I agree it COULD do so, that
> doesn't imply automatically that it does.

Fallacy: Shifting the burden of proof.

>>> #1 - Object.clone(obj) where obj.clone !== undefined #2 - 
>>> Object.clone(obj) where obj.clone === undefined
>>> 
>>> in case #1: why not just call obj.clone() ?
>> That is what I said: syntactic sugar.
> 
> "Syntactic sugar causes cancer of the semicolon." [1]

:-D

> This is redundant at best.

If there were *also* an Object.clone() method, and we were talking *only*
about *Object*.prototype.clone(), then one of them would be redundant.
Despite my sincerest efforts, you still do not seem to understand that
I did not and do not advocate for having both.

>>> in case #2: You're limited to an observable clone of public members 
>>> unless you're using black magic behind the scenes to violate 
>>> encapsulation.
>> Nonsense.
> 
> If obj.clone === undefined , you don't have a choice do you?

Apples and oranges.  As long as obj.clone === Object.prototype.clone, and
Object.prototype.clone() is a built-in, there is no functional difference
to a built-in Object.clone(obj) *instead* that calls obj.clone() *iff
defined* *instead*.  (AISB, there is a structural difference, though, that
leads to an otherwise unnecessary requirement.)

>>> If all objects are clonable in some way by default, why not just
>>> have Object.prototype.clone() ? I still don't see what the static
>>> version gives you.>> Formerly, easier for-in iteration.
> 
> Which doesn't seem relevant if you're using some unspecified built-in
> mechanism anyway in it's implementation for Case #2 above

There are two ways to have a clone() method on objects: a built-in one and a
custom one.

Before ECMASCript Ed. 5, there was no way to have non-enumerable custom
properties.  If cloning would have required defining a custom .clone()
method on an object in the prototype chain, it would have had to be filtered
out in for-in iteration.  This could have been prevented by defining a
custom Object.clone() instead (and in fact it was prevented in JSX with
jsx.object.clone()).

When specifying a new language feature, it should be considered, and ISTM it
is considered by the authors of the Editions of the ECMAScript Language
Specification, how well this feature can be provided in existing
implementations by a polyfill.

>> Since ECMAScript Ed. 5: An object does not have to have the object
>> referred to by Object.prototype in its prototype chain to be
>> cloneable.
> 
> Is it possible to not be cloneable even with a null prototype?

Only if it is implemented so explicitly.  But my point was that the same as
objects do not have to have the Object prototype in their prototype chain to
be the subject of JSON.stringify(), objects would not have to have the
Object prototype in their prototype chain to be cloneable with an
Object.clone(); their prototype chain *does not matter* (primarily).
Whether the result would always be useful then is a different question.

> Any concept of singleton?

Certainly:

  const FooSingleton = (() => {
    let _foo;

    return (function () {
      if (_foo) return _foo;

      this.bar = 42;

      _foo = this;
    });
  })();

    [Notably, (() => {…}()) is *invalid* source code instead, and arrow
     function syntax can also *not* be used for constructors.  They made
     such a mess of such a simple syntactic feature.]

But the singleton referred to by “_foo” could still be cloned.
The Singleton pattern does not imply that there could not be copies
of the singleton.

> If your *built-in* static method has privileged access, then what?

I do not think it can have that.  It was defined in a context that is
unrelated to that in which the object whose reference is passed to it
was defined.

Your point being?

> Object.clone(obj) instanceof obj ?

Usually not, the same as usually

  obj instanceof obj === false

>>> .toJSON() is a bad comparison
>> Wrong, as it follows the same approach: The caller implements the
>> method if they want object-specific behavior.
> 
> Still a bad comparison. It's only vaguely comparable because it follows
> the idiocy of ascribing meaning to an operation extrinsic to the owning
> object.

Nonsense.

> obj.toJSON() doesn't even return JSON...

It should, that is what it is for.  There is just no JSON data type (yet?),
and the return value is not validated by JSON.stringify() (yet?).

>>> and a wart on the language
>> Nonsense.
> 
> #0 - The method names are terrible. "stringify"? really?

Beautify, compactify, minify, uglify – yes, really, I do not have a problem
with “stringify” in programming.  You should not either:

<http://www.wolframalpha.com/input/?dataset=&i=*ify>

But if you think you have a better idea, name it and perhaps submit it to
es-discuss.

> #1 - obj.toJSON() doesn't return JSON

Fallacies: Bare assertion, hasty generalization.

> #2 - It's not functional due to .toJSON() requirement on target

Nonsense.  AISB, *there* *is* *no* *such* *requirement*.

> #3 - Neither is it OO due to static call against another object

Utter nonsense.  This is how OO wrappers work.

> #4 - The schema is dictated dictated extrinsically

If by that you mean that JSON is not defined in ECMAScript, that is correct.
Neither was/is XML for E4X, and JavaScript XML in React, and XPath for
document.evaluate(), to name a few.  I do not have a problem with that either.

> #5 - It can not evolve by definition

Yes it can, at least in Google V8 JavaScript in Chromium 57 where the “JSON”
and “JSON.stringify” properties have the [[Writable]] attribute.  ECMAScript
Edition 8.0 makes no different requirements.

> #5a - Bugs are permanent

Cite evidence.

> #6 - It can not encode cyclical structures or represent references

That is more a shortcoming of JSON, not JSON.stringify().

For example, if there were a YAML.stringify() [and there will be], it would
have to be able to _serialize_ cyclical structures, at least references, as
YAML supports that.

Of course, as both the “JSON” and “JSON.stringify” property values can be
overwritten (at least in Google V8 in Chromîum 57), or the serialization can
be implemented elsewhere, you are free to write serialization and parsing
methods for JSONR™, the to-be-specified JSON variant that supports internal
references.  In fact, this wheel has been invented several times now; see
also <https://stackoverflow.com/q/4001474/855543>.

> #6a […] #8

Fallacy: Red herring.

>>> The problem with JSON.stringify() and your Object.clone() is that
>>> you throw away subtype polymorphism with it.
>> Nonsense.
> 
> Prove it.

Fallacy: Shifting the burden of proof.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#35416

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >>> *built-in* does not automatically imply black-magic access to the 
> >>> internal state of the object
> >> 
> >> Yes it does.
> > 
> > Insufficient. Show evidence to justify. I agree it COULD do so, that
> > doesn't imply automatically that it does.
> 
> Fallacy: Shifting the burden of proof.

It's your claim, not mine and therefore your burden. 

> > "Syntactic sugar causes cancer of the semicolon." [1]
> 
> :-D

It's a cute saying, but the intent as I've come to understand it is that it's often a bad or false abstraction and hides important details, and has a tendency to not compose well. There is a nice wiki describing their problems with syntactic sugar that you might find interesting:

<https://wiki.haskell.org/Syntactic_sugar/Cons>

> >>> in case #2: You're limited to an observable clone of public members 
> >>> unless you're using black magic behind the scenes to violate 
> >>> encapsulation.
> >> Nonsense.
> > 
> > If obj.clone === undefined , you don't have a choice do you?
> 
> Apples and oranges.  As long as obj.clone === Object.prototype.clone, and
> Object.prototype.clone() is a built-in, there is no functional difference
> to a built-in Object.clone(obj) *instead* that calls obj.clone() *iff
> defined* *instead*.  (AISB, there is a structural difference, though, that
> leads to an otherwise unnecessary requirement.)

ok.

> >>> If all objects are clonable in some way by default, why not just
> >>> have Object.prototype.clone() ? I still don't see what the static
> >>> version gives you.>> Formerly, easier for-in iteration.
> > 
> > Which doesn't seem relevant if you're using some unspecified built-in
> > mechanism anyway in it's implementation for Case #2 above
> 
> There are two ways to have a clone() method on objects: a built-in one and a
> custom one.

ok

> Before ECMASCript Ed. 5, there was no way to have non-enumerable custom
> properties.  If cloning would have required defining a custom .clone()
> method on an object in the prototype chain, it would have had to be filtered
> out in for-in iteration.  This could have been prevented by defining a
> custom Object.clone() instead (and in fact it was prevented in JSX with
> jsx.object.clone()).

Yes, I remember.

> When specifying a new language feature, it should be considered, and ISTM it
> is considered by the authors of the Editions of the ECMAScript Language
> Specification, how well this feature can be provided in existing
> implementations by a polyfill.

> >> Since ECMAScript Ed. 5: An object does not have to have the object
> >> referred to by Object.prototype in its prototype chain to be
> >> cloneable.
> > 
> > Is it possible to not be cloneable even with a null prototype?
 
> Only if it is implemented so explicitly. 

Ok, I think i understand what you're proposing now. 

> But my point was that the same as
> objects do not have to have the Object prototype in their prototype chain to
> be the subject of JSON.stringify(), objects would not have to have the
> Object prototype in their prototype chain to be cloneable with an
> Object.clone(); their prototype chain *does not matter* (primarily).
> Whether the result would always be useful then is a different question.

In this case, does Object.clone(obj) access non-public members? 
 
> > Any concept of singleton?
> 
> Certainly:
> 
>   const FooSingleton = (() => {
>     let _foo;
> 
>     return (function () {
>       if (_foo) return _foo;
> 
>       this.bar = 42;
> 
>       _foo = this;
>     });
>   })();
> 
>     [Notably, (() => {…}()) is *invalid* source code instead, and arrow
>      function syntax can also *not* be used for constructors.  They made
>      such a mess of such a simple syntactic feature.]
> 
> But the singleton referred to by “_foo” could still be cloned.
> The Singleton pattern does not imply that there could not be copies
> of the singleton.
> 
> > If your *built-in* static method has privileged access, then what?
> 
> I do not think it can have that.  It was defined in a context that is
> unrelated to that in which the object whose reference is passed to it
> was defined.
>
> Your point being?

I was under the impression that you were sweeping some dirty details into the implementation of Object.clone() and that the runtime was using it as a backdoor to access the contents of the closure. If that is not the case then I don't think I have any argument or complaint anymore about the main idea of your proposal.

> > Object.clone(obj) instanceof obj ?
> 
> Usually not, the same as usually
> 
>   obj instanceof obj === false

ok. 

> >>> .toJSON() is a bad comparison
> >> Wrong, as it follows the same approach: The caller implements the
> >> method if they want object-specific behavior.
> > 
> > Still a bad comparison. It's only vaguely comparable because it follows
> > the idiocy of ascribing meaning to an operation extrinsic to the owning
> > object.
> 
> Nonsense.

You have Object.clone(obj) and optionally obj.clone() to specify cloning... The former which calls the latter

> > obj.toJSON() doesn't even return JSON...
> 
> It should, that is what it is for.  There is just no JSON data type (yet?),
> and the return value is not validated by JSON.stringify() (yet?).

It does not. It returns an object, and that object is what is turned into JSON by stringify

> >>> and a wart on the language
> >> Nonsense.
> > 
> > #0 - The method names are terrible. "stringify"? really?
> 
> Beautify, compactify, minify, uglify – yes, really, I do not have a problem
> with “stringify” in programming.  You should not either:
> 
> <http://www.wolframalpha.com/input/?dataset=&i=*ify>

Regularity matters. Also using antonyms. 

> But if you think you have a better idea, name it and perhaps submit it to
> es-discuss.

That ship has sailed. It's frozen in time. Hopefully no more bad names slip through:

<https://twitter.com/mlhaufe/status/971586990172000256>

Better names would have been:

serialize <==> deserialize

> > #1 - obj.toJSON() doesn't return JSON
> 
> Fallacies: Bare assertion, hasty generalization.

See the reply above and see the spec. This is just lazy.

> > #2 - It's not functional due to .toJSON() requirement on target
> 
> Nonsense.  AISB, *there* *is* *no* *such* *requirement*.

Irrelevant. It's a language smell. 

> > #3 - Neither is it OO due to static call against another object
> 
> Utter nonsense.  This is how OO wrappers work.

You do know that static methods are a code smell right? You do know that the Decorator Pattern exists as well right? What religion are you subscribing to here?

> > #4 - The schema is dictated dictated extrinsically
> 
> If by that you mean that JSON is not defined in ECMAScript, that is correct.
> Neither was/is XML for E4X, and JavaScript XML in React, and XPath for
> document.evaluate(), to name a few.  I do not have a problem with that either.

No, I'm referring to the fact that the meaning of the structure depends on the program that created it and the program that is parsing it. This shortcoming is why the wheel is being reinvented with things like JSON Schema.

> > #5 - It can not evolve by definition
> 
> Yes it can, at least in Google V8 JavaScript in Chromium 57 where the “JSON”
> and “JSON.stringify” properties have the [[Writable]] attribute.  ECMAScript
> Edition 8.0 makes no different requirements.
> 
> > #5a - Bugs are permanent
> 
> Cite evidence.

This was in the thread I gave you before:

<https://esdiscuss.org/topic/json-parser-grammar#content-15>
<https://esdiscuss.org/topic/json-parser-grammar#content-16>
<https://esdiscuss.org/topic/json-parser-grammar#content-23>

> > #6 - It can not encode cyclical structures or represent references
> 
> That is more a shortcoming of JSON, not JSON.stringify().

Which is what I was referring to

> For example, if there were a YAML.stringify() [and there will be], it would
> have to be able to _serialize_ cyclical structures, at least references, as
> YAML supports that.

yes

> Of course, as both the “JSON” and “JSON.stringify” property values can be
> overwritten (at least in Google V8 in Chromîum 57), or the serialization can
> be implemented elsewhere, you are free to write serialization and parsing
> methods for JSONR™, the to-be-specified JSON variant that supports internal
> references.  In fact, this wheel has been invented several times now; see
> also <https://stackoverflow.com/q/4001474/855543>.

Yes, I tried to push for something syntactically similar to Sharp Variables in serialization back in 2009 but it didn't make it.

<https://developer.mozilla.org/en-US/docs/Archive/Web/Sharp_variables_in_JavaScript>

> > #6a […] #8
> 
> Fallacy: Red herring.

Fallacy: Misapplication and misunderstanding of the points.

#6a You should have coupled with your reply to #6 above

and #7 is the same as your reply to #6

As for #8, it's a code smell and relevant to the topic of it being a wart.

> >>> The problem with JSON.stringify() and your Object.clone() is that
> >>> you throw away subtype polymorphism with it.
> >> Nonsense.
> > 
> > Prove it.
> 
> Fallacy: Shifting the burden of proof.

Once again, this is your proposal. You should see this as obvious by the simple fact that it's a static method. You could have simply said you don't care, or that you push the burden on the user of your proposal to worry about it. This just reads like a cop-out.

[toc] | [prev] | [next] | [standalone]

#35417

Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Michael Haufe (TNO) wrote:
>>>>> *built-in* does not automatically imply black-magic access to the 
>>>>> internal state of the object
>>>> Yes it does.
>>> Insufficient. Show evidence to justify. I agree it COULD do so, that
>>> doesn't imply automatically that it does.
>> Fallacy: Shifting the burden of proof.
> 
> It's your claim, not mine and therefore your burden. 

Wrong, you claimed (as quoted above):

“*built-in* does not automatically imply black-magic access to the
internal state of the object”

Substantiate or retract that claim.

> [tl;dr]


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#35418

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Michael Haufe (TNO) wrote:
> >>>>> *built-in* does not automatically imply black-magic access to the 
> >>>>> internal state of the object
> >>>> Yes it does.
> >>> Insufficient. Show evidence to justify. I agree it COULD do so, that
> >>> doesn't imply automatically that it does.
> >> Fallacy: Shifting the burden of proof.
> > 
> > It's your claim, not mine and therefore your burden. 
> 
> Wrong, you claimed (as quoted above):
> 
> “*built-in* does not automatically imply black-magic access to the
> internal state of the object”
> 
> Substantiate or retract that claim.

Back at you. You said it does, I don't believe you. YOU have to substantiate or retract. Proving a negative is a logical fallacy as you should know. See Russell's teapot
 
> > [tl;dr]

Surprise surprise...

[toc] | [prev] | [next] | [standalone]

#35265

Andrew Poulos wrote:
> If I have a some what large object (ie an object with lots of properties 
> that looks like:
> 
> var obj = {
>             "1": {"a":1, 
> "b":"data:text/plain;charset=UTF-8;page=21,the%20data:1234,5678", "c":3, 
> ...},
>             "2": {"a":2, ...
>             "3": ...
>             ...
>            };
> 
> You cannot add or delete any property from a top level value eg within 
> the object {"a":1, "b"... )
> All the top level values have the same properties.
> Top level properties may be added or deleted.
> 
> Is their some approach I can follow to make a multiple level undo?
> 
> I started by making copies of the object each time it was changed but 
> within minutes there was a huge number of copies. I thought about 
> limiting the undo level to, say, 8 levels but if you set a property 
> value to the value it currently is (ie. you don't actually change the 
> value) it was still recording it as a change - so trying to do an undo 
> did "nothing".
> 
> I need something that does:
> 
> 1. Has the object has been changed?
> 2. If, yes, what was the change eg obj['1'].a value changed from 1 to 2
> 3. When the user calls undo it finds the change and reverses it.

There is a design pattern called the Command Pattern that can apply here. I created a simple example of this in TypeScript here:

<https://gist.github.com/mlhaufe/c42f6ea90658d0897938487c10eb8b8e>

You can also look into the approach of structural sharing of your object:

<script type="text/typescript">

class Address {
    constructor(
        readonly company: string,
        readonly email: string,
        readonly phone: string
    ) {}
}

class Employee {
    constructor(
        readonly name: string,
        readonly salary: number,
        readonly address: Address
    ) {}
}

let e1 = new Employee(
    "John Doe",
    30_000,
    new Address(
        "Acme",
        "john.doe@example.com",
        "555-5555"
    )
)

let e2 = new Employee(
    "Jane Doe",
    e1.salary,
    e1.address
) 

let e3 = new Employee(
    e2.name,
    e2.salary,
    new Address(
        "Bad Example Studio",
        "jane.doe@example.com",
        e2.address.phone
    )
)

</script>

This is a bit too manual though I agree, but if you add a clone() method to the classes they could have a differential passed to it:

let e4 = e3.clone({
    salary: 10_000,
    address: e3.address.clone({
        phone: '444-4444'
    })
})

[toc] | [prev] | [next] | [standalone]

#35268

On Friday, 22 June 2018 00:09:28 UTC+2, Michael Haufe (TNO)  wrote:

> There is a design pattern called the Command Pattern that can apply here.

You fucking idiot: now justify how that pattern is the way to go: relative to
the "immediate" approach I have mentioned and you get extra point.

<gift>
You clueless morons, at least try and *engage*: this (programming and, more
broadly development) is NOT a matter of taste or opinions!  Note and ponder
this.
</gift>

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#35270

 Julio Di Egidio wrote:
> On Friday, 22 June 2018 00:09:28 UTC+2, Michael Haufe (TNO)  wrote:
> 
> > There is a design pattern called the Command Pattern that can apply here.
> 
> You fucking idiot: now justify how that pattern is the way to go: relative to
> the "immediate" approach I have mentioned and you get extra point.

You're obviously off your meds, or (more likely) too shallow to understand what is presented, *again*. I provided an explanatory example in the link you conveniently left out.
 
> <gift>
> You clueless morons, at least try and *engage*: this (programming and, more
> broadly development) is NOT a matter of taste or opinions!  Note and ponder
> this.
> </gift>

Indeed, it's programming. Now show us your code and not retreat into abstract nonsense.

[toc] | [prev] | [next] | [standalone]

#35271

On Friday, 22 June 2018 01:57:44 UTC+2, Michael Haufe (TNO)  wrote:

> You're obviously off your meds

You are obviously retarded and not even honest at that.

*Plonk*

Julio

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.javascript

csiph-web