[squeak-dev] Object >> #copyFrom: vs Object >> #copySameFrom:

Jakob Reschke forums.jakob at resfarm.de
Sat Jan 4 16:26:57 UTC 2020


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 at 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 at lists.squeakfoundation.org> im
> Auftrag von Jakob Reschke <forums.jakob at 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 at 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 at lists.squeakfoundation.org> im
>> Auftrag von Levente Uzonyi <leves at 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 at lists.squeakfoundation.org> im
>> Auftrag von Levente Uzonyi <leves at 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 at lists.squeakfoundation.org> im
>> Auftrag von Levente Uzonyi <leves at 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
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200104/338b3fa4/attachment.html>


More information about the Squeak-dev mailing list