January 2021 - Pharo-users - lists.pharo.org

Re: Can a class be not equal to itself?

by ducasse

Hi konrad in fact I introduced postCopy/copy long time ago and did not get the force to clean the deepCopy and veryDeepInner mess. This is something that one day we will have to do. S > On 2 Jan 2021, at 12:17, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > "Richard O'Keefe" <raoknz(a)gmail.com> writes: > >> Well, when you talk about "THE copying machinery" you have to be a bit more >> specific. There is no such thing as #deepCopy or #shallowCopy in the ANSI >> Smalltalk standard. Many Smalltalks have > > I am referring only to Pharo, which is the only Smalltalk I have ever > used. > >> You will note that in Pharo, AtomicCollection, Behavior, Boolean, >> Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph, >> Point, SmallInteger, String, UndefinedObject, and perhaps others >> override #deepCopy. > > Interesting. I didn't even consider this possibility because the comment > in Object>>#deepCopy says "should never be overridden". > >> #deepCopy is *serious* "Hic sunt dracones" territory. >> It's marked on the Hunt-Lenox Globe, just beside the >> Vesuvian introitus ad infernum. > > :-) That's more or less what I discovered in my recent debugging > experiment. > >> Seriously, the OOP way to do this is >> MyClass>>immutableSnapshot >> "Answer an immutable copy of myself." >> ... >> and then whatever it takes to make precisely that happen. > > In other words, implement my own variant of deepCopy. That's probably > the safest way to go, but it also means there is no extensible > copying infrastructure that everybody can build on. > > Konrad.

Jan. 2, 2021

is there a better way

by Roelof Wobben

Hello, I have now this code : https://github.com/RoelofWobben/Rijksmuseam but it seems to be slow. Can anyone help me with a way I can use a sort of cache so the page looks first at the cache if a image is there . If so, take the image from there , if not , ask the api for the url of the image. Roelof

Jan. 2, 2021

Re: Can a class be not equal to itself?

by Konrad Hinsen

"Richard O'Keefe" <raoknz(a)gmail.com> writes: > Well, when you talk about "THE copying machinery" you have to be a bit more > specific. There is no such thing as #deepCopy or #shallowCopy in the ANSI > Smalltalk standard. Many Smalltalks have I am referring only to Pharo, which is the only Smalltalk I have ever used. > You will note that in Pharo, AtomicCollection, Behavior, Boolean, > Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph, > Point, SmallInteger, String, UndefinedObject, and perhaps others > override #deepCopy. Interesting. I didn't even consider this possibility because the comment in Object>>#deepCopy says "should never be overridden". > #deepCopy is *serious* "Hic sunt dracones" territory. > It's marked on the Hunt-Lenox Globe, just beside the > Vesuvian introitus ad infernum. :-) That's more or less what I discovered in my recent debugging experiment. > Seriously, the OOP way to do this is > MyClass>>immutableSnapshot > "Answer an immutable copy of myself." > ... > and then whatever it takes to make precisely that happen. In other words, implement my own variant of deepCopy. That's probably the safest way to go, but it also means there is no extensible copying infrastructure that everybody can build on. Konrad.

Jan. 2, 2021

Re: [exercism bowling challenge] Is there a better way to do this

by Roelof Wobben

Jan. 2, 2021

Re: Can a class be not equal to itself?

by ducasse

Hi Richard Indeed you are correct. We should continue to use and specialize postCopy. deepCopy and its friends such as veryDeepInnerInner â¦. do not smell good. Ideally I would like to remove all deepCopy and have a deepCopier that has a clear protocol and ask the objects. So may be at the end we will rewrite deepCopy but with tests and a clear semantics. S/ > On 2 Jan 2021, at 02:32, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Well, when you talk about "THE copying machinery" you have to be a bit more specific. There is no such thing as #deepCopy or #shallowCopy in the ANSI Smalltalk standard. Many Smalltalks have > Object>>copy > ^self shallowCopy postCopy > and encourage you to override #postCopy. > But nothing stops you doing > MyClass > methods for: 'copying' > copy > ^self > deepcopy > ^self > postCopy > ^self > shallowCopy > ^self > You will note that in Pharo, AtomicCollection, Behavior, Boolean, > Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph, > Point, SmallInteger, String, UndefinedObject, and perhaps others > override #deepCopy. Also, Boolean, Character, Float, SmallFloat64, > SmallInteger, Symbol, UndefinedObject, and perhaps others > override #shallowCopy. > > So it *is* possible to have singletons in Smalltalk. > Classes can be copied in Pharo because someone thought it > would be a good idea. > > On to the next point. > 'I have an object whose internal state is updated > by incoming messages. I need to take immutable snapshots of that > object's state at some points. And that I do by sending "deepCopy" > and then "beRecursivelyReadOnlyObject".' > > You do not know which objects will be copied by #deepCopy and > which won't, or if you do, you cannot be sure that that will not > change in a future release, or indeed if you load a package. > You do not know whether some of these objects will break if made > read-only. > > #deepCopy is *serious* "Hic sunt dracones" territory. > It's marked on the Hunt-Lenox Globe, just beside the > Vesuvian introitus ad infernum. > > Seriously, the OOP way to do this is > MyClass>>immutableSnapshot > "Answer an immutable copy of myself." > ... > and then whatever it takes to make precisely that happen. > > > On Fri, 1 Jan 2021 at 23:35, Konrad Hinsen <konrad.hinsen(a)fastmail.net <mailto:konrad.hinsen@fastmail.net>> wrote: > "Richard O'Keefe" <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> writes: > > > #deepCopy is one of those things that is best avoided, > > because it violates the key principle of OOP that an > > In the abstract, I agree. In practice, I don't see what else I could do > for my use case. I have an object whose internal state is updated > by incoming messages. I need to take immutable snapshots of that > object's state at some points. And that I do by sending "deepCopy" > and then "beRecursivelyReadOnlyObject". > > Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> writes: > > > It never occurred to me that it would ever be the case! > > I've always thought classes were singleton and that SomeClass copy would > > always return the sole instance of that class! > > Me too. But after taking a closer look at how copy and deepCopy work, it > seems that maintaining singletons under copy operations is impossible. > There is no way to tell the copying machinery to return the original > object instead of making a new one. Unlike e.g. Python, where this is > possible and even quite common. > > Konrad.

Jan. 2, 2021

Re: Can a class be not equal to itself?

by Richard O'Keefe

Well, when you talk about "THE copying machinery" you have to be a bit more specific. There is no such thing as #deepCopy or #shallowCopy in the ANSI Smalltalk standard. Many Smalltalks have Object>>copy ^self shallowCopy postCopy and encourage you to override #postCopy. But nothing stops you doing MyClass methods for: 'copying' copy ^self deepcopy ^self postCopy ^self shallowCopy ^self You will note that in Pharo, AtomicCollection, Behavior, Boolean, Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph, Point, SmallInteger, String, UndefinedObject, and perhaps others override #deepCopy. Also, Boolean, Character, Float, SmallFloat64, SmallInteger, Symbol, UndefinedObject, and perhaps others override #shallowCopy. So it *is* possible to have singletons in Smalltalk. Classes can be copied in Pharo because someone thought it would be a good idea. On to the next point. 'I have an object whose internal state is updated by incoming messages. I need to take immutable snapshots of that object's state at some points. And that I do by sending "deepCopy" and then "beRecursivelyReadOnlyObject".' You do not know which objects will be copied by #deepCopy and which won't, or if you do, you cannot be sure that that will not change in a future release, or indeed if you load a package. You do not know whether some of these objects will break if made read-only. #deepCopy is *serious* "Hic sunt dracones" territory. It's marked on the Hunt-Lenox Globe, just beside the Vesuvian introitus ad infernum. Seriously, the OOP way to do this is MyClass>>immutableSnapshot "Answer an immutable copy of myself." ... and then whatever it takes to make precisely that happen. On Fri, 1 Jan 2021 at 23:35, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > "Richard O'Keefe" <raoknz(a)gmail.com> writes: > > > #deepCopy is one of those things that is best avoided, > > because it violates the key principle of OOP that an > > In the abstract, I agree. In practice, I don't see what else I could do > for my use case. I have an object whose internal state is updated > by incoming messages. I need to take immutable snapshots of that > object's state at some points. And that I do by sending "deepCopy" > and then "beRecursivelyReadOnlyObject". > > Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> writes: > > > It never occurred to me that it would ever be the case! > > I've always thought classes were singleton and that SomeClass copy would > > always return the sole instance of that class! > > Me too. But after taking a closer look at how copy and deepCopy work, it > seems that maintaining singletons under copy operations is impossible. > There is no way to tell the copying machinery to return the original > object instead of making a new one. Unlike e.g. Python, where this is > possible and even quite common. > > Konrad. >

Jan. 2, 2021

Re: Can a class be not equal to itself?

by Konrad Hinsen

"Richard O'Keefe" <raoknz(a)gmail.com> writes: > #deepCopy is one of those things that is best avoided, > because it violates the key principle of OOP that an In the abstract, I agree. In practice, I don't see what else I could do for my use case. I have an object whose internal state is updated by incoming messages. I need to take immutable snapshots of that object's state at some points. And that I do by sending "deepCopy" and then "beRecursivelyReadOnlyObject". Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> writes: > It never occurred to me that it would ever be the case! > I've always thought classes were singleton and that SomeClass copy would > always return the sole instance of that class! Me too. But after taking a closer look at how copy and deepCopy work, it seems that maintaining singletons under copy operations is impossible. There is no way to tell the copying machinery to return the original object instead of making a new one. Unlike e.g. Python, where this is possible and even quite common. Konrad.

Jan. 1, 2021

Re: Can a class be not equal to itself?

by Benoit St-Jean

It never occurred to me that it would ever be the case! I've always thought classes were singleton and that SomeClass copy would always return the sole instance of that class! I wonder what are the implications of returning a copy, say, when you add an instVar to the "original" class ?Â What happens to the reshaping of the instances created by the copy? On 2020-12-31 20:25, Richard O'Keefe wrote: > Squeak, VisualWorks, > GNU Smalltalk, and Pharo *deliberately* make > aClass copy -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth GitHub: bstjean Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Jan. 1, 2021

Re: Can a class be not equal to itself?

by Richard O'Keefe

What I said just now is true, but it doesn't tell the whole story. It turns out that Squeak, VisualWorks, GNU Smalltalk, and Pharo *deliberately* make aClass copy return a new class with the same superclass and methods (but no subclasses). Dolphin and VisualAge do not. So if you don't want to make copies of classes, you must avoid ALL of #deepCopy, #shallowCopy, AND #copy. On Fri, 1 Jan 2021 at 13:59, Richard O'Keefe <raoknz(a)gmail.com> wrote: > #deepCopy is one of those things that is best avoided, > because it violates the key principle of OOP that an > object is in charge of its own data and behaviour. > It can not so much break invariants as crush them and > bury them in an unmarked grave, just like #shallowCopy. > > > > On Fri, 1 Jan 2021 at 03:25, Konrad Hinsen <konrad.hinsen(a)fastmail.net> > wrote: > >> On 31/12/2020 12:19, Konrad Hinsen wrote: >> >> > It's been a while since I have encountered mysterious behavior in >> > Pharo, but today it happened. I set up a dictionary with classes as >> > keys, and got "Key not found" errors for keys that were definitely in >> > my dictionary. A quick debugging session showed the underlying issue: >> > I had two references to a class which look the same when inspected, >> > but turn out to be not identical (==) and thus not equal (=). How can >> > this happen? >> >> >> Update, after a few more debugging sessions: my dictionary is the result >> of a deepCopy operation, meaning the class has been copied. And the copy >> of a class is indeed a distinct but otherwise indistinguishable class. >> 'Object copy = Object' is 'false'. >> >> >> Konrad. >> >

Jan. 1, 2021

Re: Can a class be not equal to itself?

by Richard O'Keefe

#deepCopy is one of those things that is best avoided, because it violates the key principle of OOP that an object is in charge of its own data and behaviour. It can not so much break invariants as crush them and bury them in an unmarked grave, just like #shallowCopy. On Fri, 1 Jan 2021 at 03:25, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > On 31/12/2020 12:19, Konrad Hinsen wrote: > > > It's been a while since I have encountered mysterious behavior in > > Pharo, but today it happened. I set up a dictionary with classes as > > keys, and got "Key not found" errors for keys that were definitely in > > my dictionary. A quick debugging session showed the underlying issue: > > I had two references to a class which look the same when inspected, > > but turn out to be not identical (==) and thus not equal (=). How can > > this happen? > > > Update, after a few more debugging sessions: my dictionary is the result > of a deepCopy operation, meaning the class has been copied. And the copy > of a class is indeed a distinct but otherwise indistinguishable class. > 'Object copy = Object' is 'false'. > > > Konrad. >

Jan. 1, 2021