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 at 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 at 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 at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at 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 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
>> 
>> 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/20200106/a065a498/attachment.html>