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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#35387 — Re: Cloning an object

On Fri, 6 Jul 2018 23:51:01 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John G Harris wrote:
>> On Fri, 06 Jul 2018 00:24:09 +0200, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>> 
>>   <snip>
>>> Despite the syntax that suggests otherwise, ECMAScript objects are NOT like 
>>> that:
>>>
>>>  ,---------------------------------.
>>>  :          o : Object             :
>>>  :---------------------------------:
>>>  : +a : number = 1                 :
>>>  : ,-----------------------------. :
>>>  : :         +b : Array          : :
>>>  : : ,-------------------------. : :
>>>  : : :       +0 : Object       : : :
>>>  : : :-------------------------: : :
>>>  : : : +test : string = "test" : : :
>>>  : : `-------------------------' : :
>>>  : `-----------------------------' :
>>>  `---------------------------------'
>>>  
>>> But like this:
>>>
>>>        ,-----------------.
>>>  o --> :    : Object     :
>>>        :--------------:--:
>>>        : +a : number = 1 :   ,--------------.
>>>        : +b : Array -------> :   : Array    :
>>>        `-----------------'   :--------------:   ,-------------------------.
>>>                              : +0 : Object ---> :        : Object         :
>>>                              `--------------'   :-------------------------:
>>>                                                 : +test : string = "test" :
>>>                                                 `-------------------------'
>>   <snip>


>> There is a bijection between the two types of diagram [*].
>
>No, there is _not_.
>
>> They say the same thing.
>
>No, they do _not_.  

I'm talking about the structure of the two kinds of diagram, not about
their philosophy.

If you are given the first diagram you can construct the second
diagram. If you are given the second diagram you can construct the
first diagram. That is the key property of a bijection, alias a one to
one correspondence.

That is not a proof, of course, but it does indicate that a proof
should not be surprising.


>As you can see in the diagrams that you did not quote.

The unquoted diagrams describe the two kinds of clone. The quoted
diagrams can be used instead. The first diagram shows everything as a
big lump. Deep clone has to clone the whole lump. The second diagram
shows each object in a seperate box. Shallow clone has to clone just
the one box.

However, the second diagram does make it easier to explain the
algorithm your deep clone function is using.


>The first kind of object *contains* other objects.  For example, a box of
>chocolates *contains* chocolate bars.  The association between objects there
>is COMPOSITION: an object is *made up* of other objects.
>
>Cloning the first kind of object implicitly clones the objects it
>*contains*.  If you eat a certain number of chocolate bars in the original
>box, and had some method to clone it afterwards, for example advanced
>teleportation where the original is not destroyed, the clone would contain
>as many chocolate bars, arranged in the same way, as does the original.

A physical object such as a box of chocolates cannot be cloned. It can
only be imitated more or less accurately, which is what the
manufacturer does.

On the other hand, the diagrams are describing patterns of bits in
random access memory. Moreover, they are describing the patterns of
all possible conforming implementations. That includes
impelementations that are weird and no-one would want to use.

As a result, the diagrams are bound to be somewhat abstract and cannot
be used force a particular implementation.


>The second kind of object only *refers to* other objects.  For example, your
>thesis, if it otherwise is any good, refers to other scientific works by
>citation.  Those works are _not_ *contained* in your thesis.  Therefore,
>other people’s theses can refer to the same works or a subset of them.

My thesis includes quotations. These quotations are partial clones of
the papers and textbooks that are referred to.

Indeed, this Usenet article "contains" a clone of your article.


>Another example would be relationships of people; in those, no person is
>contained in the other, and your sibling is a child of your parents as well
>as you are.  The association there is REFERENCE.  By contrast to
>composition, this is a purely *abstract* form of association between objects.

What about families instead? A family looks like
  [ [Parents] [Children] ].
It has contained things. Now draw the diagram of the families after a
divorce and remarriages with further children. It gets quite
complicated.


>Cloning the second kind of object does _not_ *implicitly* clone the referred
>objects.  

It depends on your definiition of "cloning". That's why it's so much
better to call them "shallow clone" and "deep clone".


>That is why, if you want the second kind of object to provide data
>that are *independent* of the data that the original object provides,
>through all levels, you have to perform a “*deep* copy/clone”:  You have to
>clone the *referred* objects and *update* the reference in the referring
>clone to refer to the other clones.

Equivalently, you have to clone the contained objects shown in the
first diagram.

To repeat, the two diagrams use different symbols to describe the same
relation, which I will call the has_value relation just to annoy you.


>> [*] As it happens, this is proved in my thesis but the maths is not
>> for the faint-hearted.
>
>If your thesis makes that claim, then, I am sorry to break it to you, your
>thesis is *wrong*.  And one really does not need advanced maths to see that.


>Keep in mind that the way object orientation is implemented in the
>programming languages that you may know (which obviously do not include
>ECMAScript and its ECMAScript implementations) are _not_ the only way in
>which object orientation can be implemented.

The thesis was not about programming languages of any kind. It just
happened to discuss diagrams that have the same structure as your
diagrams.

  John

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

#35395 — Re: Cloning an object

On Sunday, 8 July 2018 15:39:09 UTC+2, John G Harris  wrote:

> To repeat, the two diagrams use different symbols to describe the same
> relation, which I will call the has_value relation just to annoy you.

Because you are stupid and then a liar, as the actual relation is by ref
as opposed to by val, as you have been told already.

*Plonk*

Julio

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

#35407 — Re: Cloning an object

On Sun, 8 Jul 2018 13:10:49 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Sunday, 8 July 2018 15:39:09 UTC+2, John G Harris  wrote:
>
>> To repeat, the two diagrams use different symbols to describe the same
>> relation, which I will call the has_value relation just to annoy you.
>
>Because you are stupid and then a liar, 

Ah, the usual carefully reasoned argument.


>as the actual relation 

Are you sure you know what a relation is? See Wikipedia or similar.


>is by ref
>as opposed to by val, 

You are talking about your favourite implementation of a relation.
That's irrelevant.


>as you have been told already.

That doesn't make it right.


*Plank*

  John

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

#35410 — Re: Cloning an object

On Monday, 9 July 2018 10:48:52 UTC+2, John G Harris  wrote:
> On Sun, 8 Jul 2018 13:10:49 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote:
> >On Sunday, 8 July 2018 15:39:09 UTC+2, John G Harris  wrote:
> >
> >> To repeat, the two diagrams use different symbols to describe the same
> >> relation, which I will call the has_value relation just to annoy you.
> >
> >Because you are stupid and then a liar, 
> 
> Ah, the usual carefully reasoned argument.

Just to annoy you... you hypocritical moron.

> >as the actual relation 
> 
> Are you sure you know what a relation is? See Wikipedia or similar.

Kiss my ass, you stupid cunt.

> >is by ref
> >as opposed to by val, 
> 
> You are talking about your favourite implementation of a relation.
> That's irrelevant.
 
No, I am talking about the actual technical *substance* that the first
diagram does *not* capture.  And I am just amazed that you miss the point
that the diagram is supposed to *represent something*, not the other way
round!

Julio

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

#35412 — Re: Cloning an object

On Monday, 9 July 2018 11:28:25 UTC+2, Julio Di Egidio  wrote:
> On Monday, 9 July 2018 10:48:52 UTC+2, John G Harris  wrote:
> > On Sun, 8 Jul 2018 13:10:49 -0700 (PDT), Julio Di Egidio
<snip>
> > > is by ref as opposed to by val, 
> > 
> > You are talking about your favourite implementation of a relation.
> > That's irrelevant.
>  
> No, I am talking about the actual technical *substance* that the first
> diagram does *not* capture.  And I am just amazed that you miss the point
> that the diagram is supposed to *represent something*, not the other way
> round!

BTW, that's still Mathematics uber alles all over the place,
and you are all just a bunch of hopeless retards...

*Plonk*

Julio

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

#35414 — Re: Cloning an object

On Sun, 8 Jul 2018 13:10:49 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

  <snip>
>Because you are stupid and then a liar, 
  <snip>

I'm puzzled. In what particular do you think I've lied ?

  John

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

#35342

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). As such, Object.prototype.clone() is required instead of Object.clone(), otherwise you're simply making an "observable clone".

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.

Non trivial, but somewhat related is the recent research paper you might have seen:

<http://web.cecs.pdx.edu/~black/publications/egal.pdf>

Given that Mark Miller is a co-author, I hold out hope that this can feed back into the language committee.

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

#35344

Michael Haufe (TNO) wrote:

> 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:
> 
> <http://web.cecs.pdx.edu/~black/publications/egal.pdf>

Thanks, I will read it later.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#35345

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> 
> > 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:

as a minimalist I ask, why bother having both? The instance method seems to be the minimal requirement if you're not introducing new syntax

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

#35346

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > 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).
>> […]
>> > 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:
> 
> as a minimalist I ask, why bother having both? The instance method seems
> to be the minimal requirement if you're not introducing new syntax

I did not say “both”.  Also, that is not what you were arguing.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#35347

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

> > as a minimalist I ask, why bother having both? The instance method seems
> > to be the minimal requirement if you're not introducing new syntax
> 
> I did not say “both”.  Also, that is not what you were arguing.

You were using JSON.stringify() as an analogy, which implied to me that you were advocating for an Object.clone(instance) method that potentially calls instance.clone(), and my response is why bother with the static one at all? What would that give you? It wouldn't have privileged access to the internals of the target. I don't see how Object.prototype.clone() could just be "syntactic sugar". 

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

#35348

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > as a minimalist I ask, why bother having both? The instance method
>> > seems to be the minimal requirement if you're not introducing new
>> > syntax
>> I did not say “both”.  Also, that is not what you were arguing.
> 
> You were using JSON.stringify() as an analogy, which implied to me that
> you were advocating for an Object.clone(instance) method that potentially
> calls instance.clone(),

It was not implied, but was in my stub code explicitly.  UTSL.

> and my response is why bother with the static one
> at all? What would that give you? It wouldn't have privileged access to
> the internals of the target. I don't see how Object.prototype.clone()
> could just be "syntactic sugar".

Again, that is _not_ what you argued before.

However, as should be obvious from my stub code, having both the static 
method and the dynamic one [again, I did _not_ advocate for *both*
*built-in* *Object*.prototype.clone() *and* Object.clone()] has the 
advantage that custom cloning behavior MAY easily be specified for an object 
without rewriting the caller code, for example to handle the special object 
state that you were talking about.  Think of it like the possibility of 
overloading a (“clone”) operator (which is what I actually do in JSX:math).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#35350

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

> > You were using JSON.stringify() as an analogy, which implied to me that
> > you were advocating for an Object.clone(instance) method that potentially
> > calls instance.clone(),
> 
> It was not implied, but was in my stub code explicitly.  UTSL.

Heh, first time I've seen that initialism.

> > and my response is why bother with the static one
> > at all? What would that give you? It wouldn't have privileged access to
> > the internals of the target. I don't see how Object.prototype.clone()
> > could just be "syntactic sugar".
> 
> Again, that is _not_ what you argued before.

What is it you think I argued?

> However, as should be obvious from my stub code, having both the static 
> method and the dynamic one [again, I did _not_ advocate for *both*
> *built-in* *Object*.prototype.clone() *and* Object.clone()] has the 
> advantage that custom cloning behavior MAY easily be specified for an object 
> without rewriting the caller code, for example to handle the special object 
> state that you were talking about.  Think of it like the possibility of 
> overloading a (“clone”) operator (which is what I actually do in JSX:math).

ACK

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

#35351

Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>>> and my response is why bother with the static one at all? What would
>>> that give you? It wouldn't have privileged access to the internals of
>>> the target. I don't see how Object.prototype.clone() could just be
>>> "syntactic sugar".
>> Again, that is _not_ what you argued before.
> 
> What is it you think I argued?

<1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com>
<https://groups.google.com/forum/?hl=en#!search/messageid$3A1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com>

| […] There is potentially, and probably, an associated state which is
| unobservable from outside the object (due to encapsulation). As such,
| Object.prototype.clone() is required instead of Object.clone(), otherwise
| you're simply making an "observable clone".


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

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

#35361

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >>> and my response is why bother with the static one at all? What would
> >>> that give you? It wouldn't have privileged access to the internals of
> >>> the target. I don't see how Object.prototype.clone() could just be
> >>> "syntactic sugar".
> >> Again, that is _not_ what you argued before.
> > 
> > What is it you think I argued?
> 
> <1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com>
> <https://groups.google.com/forum/?hl=en#!search/messageid$3A1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com>
> 
> | […] There is potentially, and probably, an associated state which is
> | unobservable from outside the object (due to encapsulation). As such,
> | Object.prototype.clone() is required instead of Object.clone(), otherwise
> | you're simply making an "observable clone".
> 

Yes and I stand by that still, but I'm not sure where we disagree, if we actually do at all. My latter comments were against a position you didn't hold (after your clarification).

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

#35362

Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Michael Haufe (TNO) wrote:
>>>>> and my response is why bother with the static one at all? What
>>>>> would that give you? It wouldn't have privileged access to the
>>>>> internals of the target. I don't see how Object.prototype.clone()
>>>>> could just be "syntactic sugar".
>>>> Again, that is _not_ what you argued before.
>>> What is it you think I argued?
>> 
>> <1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com> 
>> <https://groups.google.com/forum/?hl=en#!search/messageid$3A1903c1d9-646d-4518-b566-04c17a4f4a9d@googlegroups.com>
>> 
>> | […] There is potentially, and probably, an associated state which is
>> | unobservable from outside the object (due to encapsulation). As
>> | such, Object.prototype.clone() is required instead of Object.clone(),
>> | otherwise you're simply making an "observable clone".
> 
> Yes and I stand by that still, but I'm not sure where we disagree,
> if we actually do at all.

You claim(ed) above that it makes a difference regarding also cloning
“an associated state” of an object whether *either* a *built-in*
Object.prototype.clone() *or* a *built-in* Object.clone() is available.

I disagree with that claim of yours.  There is no good reason why that
should make a difference for a *built-in* method.  AISB, if there were
*built-in*

  obj.clone()

*instead of* *built-in*

  Object.clone(obj)

then obj.clone() would just be syntactic sugar.

> My latter comments were against a position you didn't
> hold (after your clarification).

Wrong; you *really* need to read more carefully.  Once again (and probably
for the last time now):

I did _not_ and I do _not_ advocate for having *both* a built-in
Object.prototype.clone() method and a built-in Object.clone() method.

Instead, I advocated for having a (built-in) Object.clone() method that
calls the .clone() method of the object referred to by the first argument of
Object.clone(), *if said object has such a method*; if said object does not
have such a method, perform a to-be-specified standardized cloning instead.

Because an Object.prototype.clone() method is _not_ required that
Object.clone() can call a .clone() method on an object to handle
object-specific cloning: that object can have a *different* prototype from
which it *inherits* the method, or it can have an *own* .clone() method.

For comparison, an object whose reference can be passed as first argument to
JSON.stringify() is also _not_ *required* to have a .toJSON() method, and
there is no Object.prototype.toJSON() method either.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

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

#35371

Thomas 'PointedEars' Lahn wrote:

> You claim(ed) above that it makes a difference regarding also cloning
> “an associated state” of an object whether *either* a *built-in*
> Object.prototype.clone() *or* a *built-in* Object.clone() is available.
> 
> I disagree with that claim of yours.  There is no good reason why that
> should make a difference for a *built-in* method.  AISB, if there were
> *built-in*
> 
>   obj.clone()
> 
> *instead of* *built-in*
> 
>   Object.clone(obj)
> 
> then obj.clone() would just be syntactic sugar.

*built-in* does not automatically imply black-magic access to the internal state of the object if you are maintaining the semantics and regularity of the language. In the case of Object.clone(obj), there is no way to access the internal state of *obj* without breaking encapsulation. Different semantics should use different syntax.

> Once again (and probably for the last time now):
> 
> I did _not_ and I do _not_ advocate for having *both* a built-in
> Object.prototype.clone() method and a built-in Object.clone() method.

Fine

> Instead, I advocated for having a (built-in) Object.clone() method that
> calls the .clone() method of the object referred to by the first argument of
> Object.clone(), *if said object has such a method*; if said object does not
> have such a method, perform a to-be-specified standardized cloning instead.

Ah yes, this is our main issue. You have a distinction that I don't think makes a difference.

#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() ?

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.

> Because an Object.prototype.clone() method is _not_ required that
> Object.clone() can call a .clone() method on an object to handle
> object-specific cloning: that object can have a *different* prototype from
> which it *inherits* the method, or it can have an *own* .clone() method.

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.

> For comparison, an object whose reference can be passed as first argument to
> JSON.stringify() is also _not_ *required* to have a .toJSON() method, and
> there is no Object.prototype.toJSON() method either.

.toJSON() is a bad comparison and a wart on the language (dictated by Crockford's initial implementation)

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

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

#35376

Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> You claim(ed) above that it makes a difference regarding also cloning 
>> “an associated state” of an object whether *either* a *built-in* 
>> Object.prototype.clone() *or* a *built-in* Object.clone() is
>> available.
>> 
>> I disagree with that claim of yours.  There is no good reason why that 
>> should make a difference for a *built-in* method.  AISB, if there were 
>> *built-in*
>> 
>> obj.clone()
>> 
>> *instead of* *built-in*
>> 
>> Object.clone(obj)
>> 
>> then obj.clone() would just be syntactic sugar.
> 
> *built-in* does not automatically imply black-magic access to the
> internal state of the object

Yes it does.

>> Instead, I advocated for having a (built-in) Object.clone() method
>> that calls the .clone() method of the object referred to by the first
>> argument of Object.clone(), *if said object has such a method*; if said
>> object does not have such a method, perform a to-be-specified
>> standardized cloning instead.
> 
> Ah yes, this is our main issue. You have a distinction that I don't think
> makes a difference.

And you are wrong about that.

> #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.

> 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.

>> Because an Object.prototype.clone() method is _not_ required that 
>> Object.clone() can call a .clone() method on an object to handle 
>> object-specific cloning: that object can have a *different* prototype
>> from which it *inherits* the method, or it can have an *own* .clone()
>> method.
> 
> 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.  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.

>> For comparison, an object whose reference can be passed as first
>> argument to JSON.stringify() is also _not_ *required* to have a
>> .toJSON() method, and there is no Object.prototype.toJSON() method
>> either.
> 
> .toJSON() is a bad comparison

Wrong, as it follows the same approach: The caller implements the method if
they want object-specific behavior.

> and a wart on the language

Nonsense.

> (dictated by Crockford's initial implementation)

Cite evidence.

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

Nonsense.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

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

#35383

On Sunday, 8 July 2018 11:14:02 UTC+2, Thomas 'PointedEars' Lahn  wrote:
> Michael Haufe (TNO) wrote:
<snip>
> > .toJSON() is a bad comparison
> 
> Wrong, as it follows the same approach: The caller implements the method if
> they want object-specific behavior.
> 
> > and a wart on the language
> 
> Nonsense.
> 
> > (dictated by Crockford's initial implementation)
> 
> Cite evidence.

I admire your patience, I'd have just replied STFU at that point... ;)

Julio

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

#35398

Julio Di Egidio wrote:
> 
> I admire your patience, I'd have just replied STFU at that point... ;)

Adults are talking. Go drink your juice.

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

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

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

csiph-web