Object >> #copyFrom: vs Object >> #copySameFrom:

Hi all,

I don't get the actual difference between #copyFrom: and #copySameFrom:.

The latter looks more "modern" to me, as it uses a primitive and has several implementors.

In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:

c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''.

c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''.

o1 := c1 new

instVarNamed: #foo put: 6;

instVarNamed: #bar put: 7.

o2 := o1 as: c2.

o2 instVarAt: 1 "nil".

o2 copySameFrom: o1.

o2 instVarAt: 1 "nil".

fooClass := Object newUniqueClassInstVars: 'a b' classInstVars: ''.

barClass := Object newUniqueClassInstVars: 'b c' classInstVars: ''.

foo := fooClass new.

bar := barClass new

instVarNamed: #b put: 2;

instVarNamed: #c put: 3;

yourself.

foo copyFrom: bar.

foo instVarNamed: #b "expected: 2, actual: nil"

copyFrom: anotherObject

"Copy to myself all instance variables I have in common with anotherObject.  This is dangerous because it ignores an object's control over its own inst vars.  "

| otherInstVars |

<primitive: 168>

otherInstVars := (anotherObject class allInstVarNames

withIndexCollect: [:name :index | name -> (anotherObject instVarAt: index)])

as: Dictionary.

self class allInstVarNames withIndexDo: [:name :index |

otherInstVars at: name ifPresent: [:value |

self instVarAt: index put: value]].

(self class isVariable and: [anotherObject class isVariable]) ifTrue: [

1 to: (self basicSize min: anotherObject basicSize) do: [:ind |

self basicAt: ind put: (anotherObject basicAt: ind)]].

c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''.

c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''.

o1 := c1 new

instVarNamed: #foo put: 6;

instVarNamed: #bar put: 7;

yourself.

o2 := c1 new.

o2 copyFrom: o1.

o2 instVarAt: 1 "6".

@Jakob: I know that. But if we have an implementation, it should be right, shouldn't it? And this is commonly used in Object >> #as: or Object class >> #newFrom:.

Best,

Christoph

On Jan 4, 2020, at 08:19, Jakob Reschke <[hidden email]> wrote:

I assume it does work for the intended use case. Probably converting between classes of the same hierarchy. That's where I used copySameFrom: once, to "dumb down" an object to one with less features (in this case: mutation methods).

Am Sa., 4. Jan. 2020 um 17:21 Uhr schrieb Thiede, Christoph <[hidden email]>:

@Jakob: I know that. But if we have an implementation, it should be right, shouldn't it? And this is commonly used in Object >> #as: or Object class >> #newFrom:.

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 4. Januar 2020 17:18:58
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

 

Keep in mind that copying the variables by name to an *unrelated* class breaks encapsulation and relying on the copying couples the classes tightly.

Am Sa., 4. Jan. 2020 um 16:03 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi Levente,

yes, that would look more intuitive for me. Why else should any of these methods ask for #allInstVarNames?

I would like to propose something like this:

copyFrom: anotherObject

"Copy to myself all instance variables I have in common with anotherObject.  This is dangerous because it ignores an object's control over its own inst vars.  "

| otherInstVars |

<primitive: 168>

otherInstVars := (anotherObject class allInstVarNames

withIndexCollect: [:name :index | name -> (anotherObject instVarAt: index)])

as: Dictionary.

self class allInstVarNames withIndexDo: [:name :index |

otherInstVars at: name ifPresent: [:value |

self instVarAt: index put: value]].

(self class isVariable and: [anotherObject class isVariable]) ifTrue: [

1 to: (self basicSize min: anotherObject basicSize) do: [:ind |

self basicAt: ind put: (anotherObject basicAt: ind)]].

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
Gesendet: Samstag, 4. Januar 2020 04:34 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

 

Hi Christoph,

On Sat, 4 Jan 2020, Thiede, Christoph wrote:

>
> Hi Levente, thanks for the feedback.
>
>
> > What's your use-case?
> Actually not a real use case, I was just confused by the confusion of both methods.
>
> But I would find it cool if my first code example would work, for the best support of converting arbitrary objects between each other.

It's not clear to me what the expected result of your first example is. Is
it that instance variables are copied by name?


Levente

>
> Best,
> Christoph
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
> Gesendet: Freitag, 3. Januar 2020 23:14:07
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:  
> Hi Christoph,
>
> On Fri, 3 Jan 2020, Thiede, Christoph wrote:
>
> >
> > Hi Levente,
> >
> >
> > I don't get that.
> >
> >
> > Did I interpret your explanation correctly?
>
> Yes, you did. I just checked why it doesn't work, and it turned out I
> misremembered how it actually works.
> The primitive's comment is:
>
>          Copy the state of the receiver from the argument.
>                  Fail if receiver and argument are of a different class.
>                  Fail if the receiver or argument are contexts (because of context-to-stack mapping).
>                  Fail if receiver and argument have different lengths (for indexable objects).
>                  Fail if the objects are not in a fit state to be copied (e.g. married contexts and Cogged methods
>
> So, it'll fail, because the classes are not the same (an artifical
> limitation IMO).
> The fallback code will only copy slots of the same index if they have the
> same name (also an artificial limitation).
>
> What's your use-case?
>
>
> Levente
>
> >
> >
> >       fooClass := Object newUniqueClassInstVars: 'a b' classInstVars: ''.
> > barClass := Object newUniqueClassInstVars: 'b c' classInstVars: ''.
> > foo := fooClass new.
> > bar := barClass new
> > instVarNamed: #b put: 2;
> > instVarNamed: #c put: 3;
> > yourself.
> > foo copyFrom: bar.
> > foo instVarNamed: #b "expected: 2, actual: nil"
> >
> >
> > Otherwise, if I put #b as the first instvar in both classes, #copyFrom: and #copySameFrom: won't differ again ...
> >
> >
> > Best,
> >
> > Christoph
> >
> >
> >________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> _
> > Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
> > Gesendet: Freitag, 3. Januar 2020 19:05 Uhr
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:  
> > Hi Christoph,
> >
> > The two methods are different. #copyFrom: copies variables by index while
> > #copySameFrom: copies variables by name.
> > So, if you have an object named foo of class Foo with 2 instance variables
> > a and b, and an object named bar of class Bar with 2 instance variables b
> > and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to
> > foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as
> > is.
> >
> > Levente
> >
> >
> > On Fri, 3 Jan 2020, Thiede, Christoph wrote:
> >
> > >
> > > Hi all,
> > >
> > >
> > > I don't get the actual difference between #copyFrom: and #copySameFrom:.
> > >
> > >
> > > The latter looks more "modern" to me, as it uses a primitive and has several implementors.
> > >
> > > In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
> > >
> > >
> > > c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''.
> > > c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''.
> > > o1 := c1 new
> > > instVarNamed: #foo put: 6;
> > > instVarNamed: #bar put: 7.
> > > o2 := o1 as: c2.
> > > o2 instVarAt: 1 "nil".
> > >
> > > o2 copySameFrom: o1.
> > > o2 instVarAt: 1 "nil".
> > >
> > >
> > > Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
> > >
> > > Best,
> > > Christoph
> > >
> > >
> > >
> >
> >
>
>

On Jan 6, 2020, at 06:41, Thiede, Christoph <[hidden email]> wrote:

You're right, this might be a more common case. But let me ask the other way around: What would be the disadvantage of extending the support for all types of class copies?

Metaprogramming must always be used with care, but I don't think this is an argument against implementing certain metaprogramming mechanisms ...

I think we should at least document the difference between both selectors better.

My problem with #copyFrom: is its description to copy "all instance variables I have in common with anotherObject".

The implementation does not really ensure the instance variables are declared in the same class and not a similar one. If we permit such incidents, we don't need to care for their order at all.

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 4. Januar 2020 17:26:57
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

 

I assume it does work for the intended use case. Probably converting between classes of the same hierarchy. That's where I used copySameFrom: once, to "dumb down" an object to one with less features (in this case: mutation methods).

Am Sa., 4. Jan. 2020 um 17:21 Uhr schrieb Thiede, Christoph <[hidden email]>:

@Jakob: I know that. But if we have an implementation, it should be right, shouldn't it? And this is commonly used in Object >> #as: or Object class >> #newFrom:.

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 4. Januar 2020 17:18:58
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

 

Keep in mind that copying the variables by name to an *unrelated* class breaks encapsulation and relying on the copying couples the classes tightly.

Am Sa., 4. Jan. 2020 um 16:03 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi Levente,

yes, that would look more intuitive for me. Why else should any of these methods ask for #allInstVarNames?

I would like to propose something like this:

copyFrom: anotherObject

"Copy to myself all instance variables I have in common with anotherObject.  This is dangerous because it ignores an object's control over its own inst vars.  "

| otherInstVars |

<primitive: 168>

otherInstVars := (anotherObject class allInstVarNames

withIndexCollect: [:name :index | name -> (anotherObject instVarAt: index)])

as: Dictionary.

self class allInstVarNames withIndexDo: [:name :index |

otherInstVars at: name ifPresent: [:value |

self instVarAt: index put: value]].

(self class isVariable and: [anotherObject class isVariable]) ifTrue: [

1 to: (self basicSize min: anotherObject basicSize) do: [:ind |

self basicAt: ind put: (anotherObject basicAt: ind)]].

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
Gesendet: Samstag, 4. Januar 2020 04:34 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

 

Hi Christoph,

On Sat, 4 Jan 2020, Thiede, Christoph wrote:

>
> Hi Levente, thanks for the feedback.
>
>
> > What's your use-case?
> Actually not a real use case, I was just confused by the confusion of both methods.
>
> But I would find it cool if my first code example would work, for the best support of converting arbitrary objects between each other.

It's not clear to me what the expected result of your first example is. Is
it that instance variables are copied by name?


Levente

>
> Best,
> Christoph
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
> Gesendet: Freitag, 3. Januar 2020 23:14:07
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:  
> Hi Christoph,
>
> On Fri, 3 Jan 2020, Thiede, Christoph wrote:
>
> >
> > Hi Levente,
> >
> >
> > I don't get that.
> >
> >
> > Did I interpret your explanation correctly?
>
> Yes, you did. I just checked why it doesn't work, and it turned out I
> misremembered how it actually works.
> The primitive's comment is:
>
>          Copy the state of the receiver from the argument.
>                  Fail if receiver and argument are of a different class.
>                  Fail if the receiver or argument are contexts (because of context-to-stack mapping).
>                  Fail if receiver and argument have different lengths (for indexable objects).
>                  Fail if the objects are not in a fit state to be copied (e.g. married contexts and Cogged methods
>
> So, it'll fail, because the classes are not the same (an artifical
> limitation IMO).
> The fallback code will only copy slots of the same index if they have the
> same name (also an artificial limitation).
>
> What's your use-case?
>
>
> Levente
>
> >
> >
> >       fooClass := Object newUniqueClassInstVars: 'a b' classInstVars: ''.
> > barClass := Object newUniqueClassInstVars: 'b c' classInstVars: ''.
> > foo := fooClass new.
> > bar := barClass new
> > instVarNamed: #b put: 2;
> > instVarNamed: #c put: 3;
> > yourself.
> > foo copyFrom: bar.
> > foo instVarNamed: #b "expected: 2, actual: nil"
> >
> >
> > Otherwise, if I put #b as the first instvar in both classes, #copyFrom: and #copySameFrom: won't differ again ...
> >
> >
> > Best,
> >
> > Christoph
> >
> >
> >________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> _
> > Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
> > Gesendet: Freitag, 3. Januar 2020 19:05 Uhr
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:  
> > Hi Christoph,
> >
> > The two methods are different. #copyFrom: copies variables by index while
> > #copySameFrom: copies variables by name.
> > So, if you have an object named foo of class Foo with 2 instance variables
> > a and b, and an object named bar of class Bar with 2 instance variables b
> > and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to
> > foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as
> > is.
> >
> > Levente
> >
> >
> > On Fri, 3 Jan 2020, Thiede, Christoph wrote:
> >
> > >
> > > Hi all,
> > >
> > >
> > > I don't get the actual difference between #copyFrom: and #copySameFrom:.
> > >
> > >
> > > The latter looks more "modern" to me, as it uses a primitive and has several implementors.
> > >
> > > In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
> > >
> > >
> > > c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''.
> > > c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''.
> > > o1 := c1 new
> > > instVarNamed: #foo put: 6;
> > > instVarNamed: #bar put: 7.
> > > o2 := o1 as: c2.
> > > o2 instVarAt: 1 "nil".
> > >
> > > o2 copySameFrom: o1.
> > > o2 instVarAt: 1 "nil".
> > >
> > >
> > > Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
> > >
> > > Best,
> > > Christoph
> > >
> > >
> > >
> >
> >
>
>

Hi John,

> By the way, I think that newUniqueClassInstVars: does something different from what you think it does. For one thing, the environment objects exist in is called EnvironmentForUniClass. In your example, o1 isn't instantiated properly, so copyFrom: finds o1 has no instVars so, it never copies the instVars to the new object.