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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede

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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede

Hi Levente,


I don't get that.


Did I interpret your explanation correctly?


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


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
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
> >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede

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.

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


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
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
> > >
> > >
> > >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede

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


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape

> On 04.01.2020, at 16:03, Thiede, Christoph <[hidden email]> wrote:
>
> 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)]].
>

Well, that won't work with the primitive, right?
-t

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



Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
In reply to this post by Christoph Thiede
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
> > >
> > >
> > >
> >
> >
>
>



Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede
In reply to this post by Tobias Pape

Well, that won't work with the primitive, right?


The primitive appears only to work for two objects of equal class & lengths, or am I wrong?


If you do


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

(using my proposed implementation),

the primitive will do its job ...


Best,

Christoph



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

> On 04.01.2020, at 16:03, Thiede, Christoph <[hidden email]> wrote:
>
> 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)]].
>

Well, that won't work with the primitive, right?
-t

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





Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede
In reply to this post by Jakob Reschke

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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
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
> > >
> > >
> > >
> >
> >
>
>




Reply | Threaded
Open this post in threaded view
|

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

Squeak - Dev mailing list
In reply to this post by Jakob Reschke
+1

/————————————————————/
For encrypted mail use [hidden email]
Get a free account at ProtonMail.com
Web: www.objectnets.net and www.objectnets.org

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


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




Reply | Threaded
Open this post in threaded view
|

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

Squeak - Dev mailing list
In reply to this post by Jakob Reschke
I might add that both methods have warnings against use.

The method comment for copyFrom: says:
This is dangerous because it ignores an object's control over its own inst vars.

The method comment from copySameFrom: says:
This ignores otherObject's control over its own inst vars.

I don't know what kind of warning you need if you ignore the method comments. Maybe referring to a book of object-oriented programming is in order. Smalltalk isn't like Python, where all the definitions of a programing style are out the window. Maybe that's why Python is so popular.

On January 4, 2020 at 9:27 AM, 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
> > >
> > >
> > >
> >
> >
>
>





Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede
In reply to this post by Jakob Reschke

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




Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

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

Squeak - Dev mailing list
Your point that documentation of the differences between the two selectors is an especially apt one. I tried to improve the method comments back when I was more active, but it appears none of my work ended up in the update stream. Maybe because it was just comments. People tend to not do comments; after it was hard to write, why shouldn’t it be difficult to read?

/————————————————————/
For encrypted mail use [hidden email]
Get a free account at ProtonMail.com
Web: www.objectnets.net and www.objectnets.org

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





Reply | Threaded
Open this post in threaded view
|

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

Squeak - Dev mailing list
In reply to this post by Christoph Thiede
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.

I fiddled around with the code and found that if I declare the objects in the System Browser the following code works:

c1 := FooBar new.
c1 instVarNamed: 'foo' put: 6.
c1 instVarNamed: 'bar' put: 7.

c2 := BarFoo new.
c2 copySameFrom: c1.
c2 instVarAt: 2.
c1 instVarAt: 2.

I couldn't get copyFrom: to work, the second instVar is nil. copyFrom: appears to only "work" when the instVars are at the same and in the same order. At least that's how I read it.

On January 6, 2020 at 7:41 AM, "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
> > >
> > >
> > >
> >
> >
>
>





Reply | Threaded
Open this post in threaded view
|

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

Christoph Thiede

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.


No no, my fault was much more stupid: I forgot a #yourself in the cascade ... Adding that, the example works fine for #copySameFrom:.

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von John Pfersich via Squeak-dev <[hidden email]>
Gesendet: Dienstag, 7. Januar 2020 07:00:33
An: The general-purpose Squeak developers list
Cc: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:
 
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.

I fiddled around with the code and found that if I declare the objects in the System Browser the following code works:

c1 := FooBar new.
c1 instVarNamed: 'foo' put: 6.
c1 instVarNamed: 'bar' put: 7.

c2 := BarFoo new.
c2 copySameFrom: c1.
c2 instVarAt: 2.
c1 instVarAt: 2.

I couldn't get copyFrom: to work, the second instVar is nil. copyFrom: appears to only "work" when the instVars are at the same and in the same order. At least that's how I read it.

On January 6, 2020 at 7:41 AM, "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
> > >
> > >
> > >
> >
> >
>
>





Carpe Squeak!