Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Freitag, 3. Januar 2020 19:05 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:
Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Freitag, 3. Januar 2020 19:05 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom: Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Freitag, 3. Januar 2020 19:05 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom: Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Freitag, 3. Januar 2020 19:05 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom: Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
Hi 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 methodsSo, 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Freitag, 3. Januar 2020 19:05 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom: Hi Christoph,
The two methods are different. #copyFrom: copies variables by index while #copySameFrom: copies variables by name. So, if you have an object named foo of class Foo with 2 instance variables a and b, and an object named bar of class Bar with 2 instance variables b and c, then foo copyFrom: bar will copy bar's b to foo's a, and bar's c to foo's b. #copySameFrom: will copy bar's b to foo's b and leave foo's a as is.
Levente
On Fri, 3 Jan 2020, Thiede, Christoph wrote:
Hi all,
I don't get the actual difference between #copyFrom: and #copySameFrom:.
The latter looks more "modern" to me, as it uses a primitive and has several implementors.
In my opinion, none of them actually matches its description ("Copy to myself all instance variables [named the same in | I have in common with] otherObject"). The following leaves o2 empty:
c1 := Object newUniqueClassInstVars: 'foo bar' classInstVars: ''. c2 := Object newUniqueClassInstVars: 'bar foo' classInstVars: ''. o1 := c1 new instVarNamed: #foo put: 6; instVarNamed: #bar put: 7. o2 := o1 as: c2. o2 instVarAt: 1 "nil".
o2 copySameFrom: o1. o2 instVarAt: 1 "nil".
Question: Could we deprecate #copySameFrom:, and in #copyFrom:, copy *all* matching instvars without respecting their order? Or did I miss any intended difference in behavior?
Best, Christoph
On 04.01.2020, at 16:03, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 methodsSo, 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Tobias Pape Das.Linux@gmx.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 methodsSo, 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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
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 < Christoph.Thiede@student.hpi.uni-potsdam.de>:
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu *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 squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Levente Uzonyi leves@caesar.elte.hu
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 (becauseof 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 squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Levente Uzonyi leves@caesar.elte.hu
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
@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
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de 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 <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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 methodsSo, 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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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
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 < Christoph.Thiede@student.hpi.uni-potsdam.de>:
@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
http://www.hpi.de/
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de *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 < Christoph.Thiede@student.hpi.uni-potsdam.de>:
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu *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 squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Levente Uzonyi leves@caesar.elte.hu
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 (becauseof 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 becopied (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 squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Levente Uzonyi leves@caesar.elte.hu
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
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 forums.jakob@resfarm.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de: @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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de: 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de 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 <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
@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
http://www.hpi.de/ ________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob@resfarm.demailto:forums.jakob@resfarm.de> 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 <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:
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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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 methodsSo, 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 <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu> 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
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 jgpfersich@protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org
On Jan 6, 2020, at 06:41, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de: @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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de: 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 methodsSo, 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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
+1
/————————————————————/ For encrypted mail use jgpfersich@protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org
On Jan 4, 2020, at 08:19, Jakob Reschke forums.jakob@resfarm.de 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 Christoph.Thiede@student.hpi.uni-potsdam.de: 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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 methodsSo, 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu 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
squeak-dev@lists.squeakfoundation.org
-
Jakob Reschke -
John Pfersich -
Levente Uzonyi -
Thiede, Christoph -
Tobias Pape