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

John Pfersich smalltalker2 at mac.com
Mon Jan 6 05:12:21 UTC 2020


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 at 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 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/12f3c07b/attachment.html>


More information about the Squeak-dev mailing list