September 2020 - Pharo-users

Re: How can I make this more OOP

by Richard O'Keefe

In a language like Java or C# or Ada we can insist at compile time that an argument conforms to a protocol, whatever class it might be an instance of. In Smalltalk, we can use #isKindOf: to test whether an object inherits from a class, but that is often the wrong test. We can use (multiple calls to) #respondsTo: to tell whether an object conforms to a protocol. The only snag, of course, is that in too many Smalltalk systems, #respondsTo: is not trustworthy. If a class has a method that sends #subclassResponsibility or #shouldNotImplement, it's still counted as responding to the selector in question. This is not a problem in my Smalltalk because (a) you are not allowed to create a direct instance of a class where any method calls #subclassResponsibility. (b) #shouldNotImplement appears only in test cases. Since I already have named protocols, with classes declaring their intention to conform to them, I've been thinking about adding aClass implements: aProtocol anInstance conformsTo: aProtocol but have not done that yet. I note that Pharo V7.0.3 had 132 senders of #respondsTo: and Pharo V8.0.0 has 126 senders of #respondsTo:. These neatly bracket Dolphin 7's 130. On Wed, 16 Sep 2020 at 06:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > On 14 Sep 2020, at 16:02, Roelof Wobben via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > Thanks Richard for this explanation. > and I like also your idea of using #respondTo instead of asking a object > if its a collection or a item. > > > refrain from using respondTo: > I make code difficult to evolve and can introduce vicious bugs. > > S. > > Roelof > > > Op 14-9-2020 om 14:28 schreef Richard O'Keefe: > > "OOP is not asking an object what it is"? You've lost me. > I'm reminded of a joke exam question that goes something > like this: > Some things have ping nature and other things have pong nature. > Discuss, with examples. > > Whatever else it is, OOP is a means to an end, not an end in itself. > It's not a religion. Allah will not cast you into the Fire for using > something which is not ritually pure. > > The whole point of the Design Patterns movement was not to present > canned solutions but to describe common *situations* characterised > by (metaphorical) *forces* pushing you in incompatible directions. > > Question 1: Why do you even have a stream there? > flattenArray: aCollection > |buffer| > buffer := OrderedCollection new: aCollection size. > self flattenArray: aCollection into: buffer. > ^buffer asArray > > flattenArray: anObject into: buffer > (anObject respondsTo: #do:) > ifTrue: [anObject do: [:each | self flattenArray: each into: > buffer] > ifFalse: [anObject ifNotNil: [buffer addLast: anObject]. > > (CAUTION: untested code.) > > Question 2: is there any point in *trying* to make this more ping and less > pong? > I have to say that in 40 years of programming, I have *never* wanted to > flatten > a completely arbitrary structure. When I have wanted to flatten > something, it > has always been an instance of the Composite design pattern, so that a > specific > and quite small set of classes has been involved. > > I am well aware that some Smalltalk systems have some sort of 'flatten' > lying around like a rake in the grass, but I have found no two which agree > on the specification. > > Question 3: Let's consider an if-less alternative. > > Stream > flattenInto: buffer > self do: [:each| each flattenInto: buffer]. > > Collection > flattenInto: buffer > self do:[:each | each flattenInto: buffer]. > > Object > flattenInto: buffer > buffer addLast: self. > > UndefinedObject > flattenInto: buffer > "Do nothing." > > This is Smalltalk, where we *can* add methods to system classes like these. > When the payoff is worth it, I have no qualms whatever in doing so. > But putting methods of little or no utility into the interface of EVERY > object just feels so wrong. > > Here we have opposing forces: > - The first approach adds two methods to your worker class, > and no methods to any system class. Instead, it uses > "does this object know how to iterate over its elements?" > and "is this object nil?". This does minimal damage to > system structure at the price of a little ritual impurity. > > - The second approach adds a method to four system classes, > enlarging the interface of every object in the system, > creating a level of coupling we'd be better without, and > making it harder for someone reading your code to figure > out what's going on. > > In the context of a Composite, with a limited number of > application classes involved, the second approach is better; > the method is/methods are not defined anywhere they should > not be. > > In the context of *this* problem, the first approach is > better. MUCH better. Why? Because *encapsulation* is much > more important to OOP than absence-of-IFs. > > On Sun, 13 Sep 2020 at 21:26, Roelof Wobben via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >> Hello, >> >> I know that OOP is not asking a object what it is but I have to flatten a >> array so I did this : >> >> flattenArray: aCollection >> ^ (OrderedCollection >> streamContents: [ :stream | self flatten: aCollection into: >> stream ]) >> asArray >> >> flatten: anObject into: result >> ^ anObject isCollection >> ifTrue: [ anObject do: [ :item | self flatten: item into: result ] ] >> ifFalse: [ anObject ifNotNil: [ result nextPut: anObject ] ] >> >> The name flattenArray is given bij exercism. >> >> Now I wonder how I can make this more a OOP solution. >> >> Can someone give me some hints or some examples ? >> >> Roelof >> >> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

Sept. 16, 2020

Re: [Pharo-dev] Updating lists.pharo.org: New server, Mailman3 and more

by StÃ©phane Ducasse

marcus I tried and I could not see the archive. Apparently the archive is still private. > On 14 Sep 2020, at 19:54, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Migration is Complete! > > If you want to login at the website, you need to create a new account with the email address that the lists are now sending emails to. > > https://lists.pharo.org <https://lists.pharo.org/> > > > >> On 14 Sep 2020, at 19:18, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> So: sending emails should now be ok, but the web-interface is still syncing the archives (pharo-dev is there, pharo-users >> will be soon). >> >> But this means that everyone should be fine to send mails again. >> >> Marcus >> >>> On 14 Sep 2020, at 19:11, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> Testing if this is send via the new serverâ¦ the new Archive is at https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org <https://lists.pharo.org/empathy/list/pharo-dev.lists.pharo.org> >>> >>> Marcus >>> >>>> On 14 Sep 2020, at 17:42, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> >>>> Hi, >>>> >>>> We are updating the mailinglists (everything https://lists.pharo.org/ <https://lists.pharo.org/>) >>>> >>>> -> New server, thus: new IPâ¦ >>>> -> the server will run Mailman3 (we used Mailman2) >>>> -> There will be a better Archive >>>> >>>> >>>> I will do the change of the IP address today. >>>> >>>> The only thing that could happen is that mails send still via the old server will not be in the >>>> new archive, everything else should be transparent. >>>> >>>> I will send another mail when it is done. >>>> >>>> Marcus >>> >> > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 15, 2020

Re: Updating lists.pharo.org: New server, Mailman3 and more

by StÃ©phane Ducasse

And the cool thing about it is that we will have soon a mailing list for github and other logs (that we can browse while not be forced to register too) and with that Pharo-dev will be less polluted and we want to have it back a place to exchange about Pharo. S.

Sept. 15, 2020

Re: How can I make this more OOP

by StÃ©phane Ducasse

> On 14 Sep 2020, at 16:02, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Thanks Richard for this explanation. > and I like also your idea of using #respondTo instead of asking a object if its a collection or a item. refrain from using respondTo: I make code difficult to evolve and can introduce vicious bugs. S. > Roelof > > > Op 14-9-2020 om 14:28 schreef Richard O'Keefe: >> "OOP is not asking an object what it is"? You've lost me. >> I'm reminded of a joke exam question that goes something >> like this: >> Some things have ping nature and other things have pong nature. >> Discuss, with examples. >> >> Whatever else it is, OOP is a means to an end, not an end in itself. >> It's not a religion. Allah will not cast you into the Fire for using >> something which is not ritually pure. >> >> The whole point of the Design Patterns movement was not to present >> canned solutions but to describe common *situations* characterised >> by (metaphorical) *forces* pushing you in incompatible directions. >> >> Question 1: Why do you even have a stream there? >> flattenArray: aCollection >> |buffer| >> buffer := OrderedCollection new: aCollection size. >> self flattenArray: aCollection into: buffer. >> ^buffer asArray >> >> flattenArray: anObject into: buffer >> (anObject respondsTo: #do:) >> ifTrue: [anObject do: [:each | self flattenArray: each into: buffer] >> ifFalse: [anObject ifNotNil: [buffer addLast: anObject]. >> >> (CAUTION: untested code.) >> >> Question 2: is there any point in *trying* to make this more ping and less pong? >> I have to say that in 40 years of programming, I have *never* wanted to flatten >> a completely arbitrary structure. When I have wanted to flatten something, it >> has always been an instance of the Composite design pattern, so that a specific >> and quite small set of classes has been involved. >> >> I am well aware that some Smalltalk systems have some sort of 'flatten' >> lying around like a rake in the grass, but I have found no two which agree >> on the specification. >> >> Question 3: Let's consider an if-less alternative. >> >> Stream >> flattenInto: buffer >> self do: [:each| each flattenInto: buffer]. >> >> Collection >> flattenInto: buffer >> self do:[:each | each flattenInto: buffer]. >> >> Object >> flattenInto: buffer >> buffer addLast: self. >> >> UndefinedObject >> flattenInto: buffer >> "Do nothing." >> >> This is Smalltalk, where we *can* add methods to system classes like these. >> When the payoff is worth it, I have no qualms whatever in doing so. >> But putting methods of little or no utility into the interface of EVERY >> object just feels so wrong. >> >> Here we have opposing forces: >> - The first approach adds two methods to your worker class, >> and no methods to any system class. Instead, it uses >> "does this object know how to iterate over its elements?" >> and "is this object nil?". This does minimal damage to >> system structure at the price of a little ritual impurity. >> >> - The second approach adds a method to four system classes, >> enlarging the interface of every object in the system, >> creating a level of coupling we'd be better without, and >> making it harder for someone reading your code to figure >> out what's going on. >> >> In the context of a Composite, with a limited number of >> application classes involved, the second approach is better; >> the method is/methods are not defined anywhere they should >> not be. >> >> In the context of *this* problem, the first approach is >> better. MUCH better. Why? Because *encapsulation* is much >> more important to OOP than absence-of-IFs. >> >> On Sun, 13 Sep 2020 at 21:26, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: >> Hello, >> >> I know that OOP is not asking a object what it is but I have to flatten a array so I did this : >> >> flattenArray: aCollection >> ^ (OrderedCollection >> streamContents: [ :stream | self flatten: aCollection into: stream ]) >> asArray >> >> flatten: anObject into: result >> ^ anObject isCollection >> ifTrue: [ anObject do: [ :item | self flatten: item into: result ] ] >> ifFalse: [ anObject ifNotNil: [ result nextPut: anObject ] ] >> >> The name flattenArray is given bij exercism. >> >> Now I wonder how I can make this more a OOP solution. >> >> Can someone give me some hints or some examples ? >> >> Roelof >> > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 15, 2020

Re: Updating lists.pharo.org: New server, Mailman3 and more

by Offray Vladimir Luna CÃ¡rdenas

+100^100. As Susan Leigh Star said, infrastructure is invisible until it fails. So all the work behind the invisible to keep it running, lean and smooth is really important. Offray On 15/09/20 3:06 a.Â m., Sven Van Caekenberghe wrote: > >> On 14 Sep 2020, at 17:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Marcus Denker-4 wrote >>> We are updating the mailinglists (everything https://lists.pharo.org/ >>> <https://lists.pharo.org/>) >> Thanks, Marcus - all this logistical stuff gets no glory but is so important >> :) > +100 > > Indeed, thank you, Marcus ! > >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 15, 2020

Re: how can I improve this

by Roelof Wobben

Sept. 15, 2020

Re: how can I improve this

by Richard O'Keefe

SequenceableCollection has with:do:. Add with: other count: testBlock |r| r := 0. self with: other do: [:x :y | (testBlock value: x value: y) ifTrue: [r := r + 1]]. ^r I have this in my library anyway. Now distanceStrand1: a strand2: b ^a with: b count: [:x :y | x ~= y] #with:do: already checks that the sequences have the same size; it's too confusing if the error reported in this case is different from the error for #with:do:. On Tue, 15 Sep 2020 at 16:59, Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Op 14-9-2020 om 22:19 schreef HernÃ¡n Morales Durand: > > ^ (1 to: self size) count: [ : i | (self at: i) ~= (aString at: i) ] > > > > With that code I get a few problems but this is working > > distanceStrand1: aString strand2: aString2 > aString size == aString2 size > ifFalse: [ DomainError signal: (self messageFor: aString strand2: > aString2) ]. > ^ (1 to: aString size) > count: [ :i | (aString2 at: i) ~= (aString at: i) ] > > Roelof > > >

Sept. 15, 2020

Re: Rounding in Floats

by Richard O'Keefe

If you are going to use floating point numbers in any programming language, Pharo included, you need to understand something about them. Things like - the relevant precision is *fixed*; a Float in Pharo is *always* a 64-bit IEEE floating-point number, which amongst other things means (to a first approximation) 54 binary digits of precision. It doesn't make the slightest amount of difference how many decimal digits you use when writing the number, the precision is *always* 54 binary digits. So you *did* get the precision out of rounding that you put in, it's just that the precision you put in was not what you thought it was. - almost all modern architectures offer BINARY arithmetic, not decimal. (The main exceptions are IBM z/series and IBM POWER, which offer binary *and* decimal.) Rounding a number to n decimals is ALWAYS problematic using binary floats. This has little or nothing to do with Smalltalk: it's the hardware. (This is why you are advised to keep money in cents, not dollars.) - Again, this is NOT a language issue, it is a hardware issue. IF you understand how binary floating point arithmetic works, then the arithmetic you get in C or R or Smalltalk or Matlab does not surprise you at all. If you DON'T understand how binary floating point arithmetic works, the hardware will *get* you sooner or later. - ScaledDecimal in Pharo didn't have to violate the principle of least surprise, but it does, big time. - It would be really nice if Pharo offered true decimal arithmetic as an option. There may already be a package for this. On Tue, 8 Sep 2020 at 15:46, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > "7.1 roundTo: 0.1 should return 7.1" > > You're still not getting it. > > I was until Konrad explained it. > > > Binary floating point CANNOT represent either of those numbers. > > You seem to be assuming that Pharo is making some mistake. > > It isn't. All it is doing is refusing to lie to you. > <snip> > > The systems that print 7.1 are LYING to you, > > and Pharo is not. > > I'm not assuming a mistake from Pharo, I had a wrong expectation what > to get if I round to that precision. > I don't know whether other systems lie or simply fulfill user > expectations, if you send the #roundTo: to a float, I did expect to > get a number with the same precision. > That is my expectation as a user. As in the other thread I expected > two scaled decimals that are printed equal to also be compared as > equal (which they don't). > > Whether there is a good reason for those behaviors is beyond my > current comprehension, but it certainly doesn't follow the "principle > of least surprise". > > In any case, the method proposed by Tomohiro solved my issues. > > Regards, > > Esteban A. Maringolo > >

Sept. 15, 2020

Re: How can I make this more OOP

by Richard O'Keefe

I take Sean's point. However, while I agree that practising using polymorphism instead of 'if' is a good idea, I don't think that *this* exercise is a good one for getting such practice. Roelof is going through the Pharo track of Exercism. This particular one is called 'flatten-array'. The one concession to "hey, this is Pharo!" in the description of the exercise is a veiled warning against using Pharo's #flattened/#flattenOn:, which (a) does not add anything to Object or UndefinedObject (just Collection>>flattened and Collection>>flattenOn:) (b) does not make a special case of nil (c) DOES make a special case of strings, treating them as atomic. Possibly the most challenging part for me in this exercise was trying to figure out "what does <list> mean for Smalltalk here?" In Pharo's existing #flattened, why does a String count as atomic but a Semphore is just another collection? This is a Lisp programming exercise from the early 1960s. It had unpleasant ambiguities back then and it has not got better since. If this were rewritten as "Make a Composite implementation of binary search trees with a class for empty trees, a class for non-empty ones, and perhaps a class for singleton ones. Implement #do:, traversing the elements in increasing order. Use this to implement #asOrderedCollection." then that *would* be a good exercise for using polymorphism instead of conditionals. BST () asOrderedCollection ^OrderedCollection new in: [:coll | self do: [:each | coll addLast: each]. coll] EmptyBST () do: aBlock "Nothing to do." NonemptyBST (less key greater) do: aBlock less do: aBlock. aBlock value: key. greater do: aBlock. On Tue, 15 Sep 2020 at 18:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Richard O'Keefe wrote > > Whatever else it is, OOP is a means to an end, not an end in itself. > > It's not a religion. > > Richard makes an important point here. > > As I mentioned on Discord (slightly edited to fit this thread), itâs a > judgment call with trade-offs, but for the purposes of an OOP exercise, I > would say absolutely put the methods in object and wherever else you may > need them - if only to get practice with that particular idiom. I needed to > do a lot of that sort of thing - probably way *too* much, just to break my > procedural thinking habits. Once I got it "in my bones" I became more > pragmatic. While in theory, this may always be the âmostâ OOP way, in > practice it can be confusing due to the limitations of our system > organization and the fact that people will have to scroll through more > methods on kernel objects (not to mention the extra dependencies Richard > noted). That is the dogma, and I think is a fine answer for an OOP > exercise, > but IMHO in practice there are justifiable exceptions. The two major axes > are understandability and adaptability. If in your domain there are only > two > choices and there can not logically be more, it may be easier to understand > one method with a conditional that documents that domain fact, than it > would > be to dive down a polymorphism rabbit hole spread across the system. Of > course, tooling is a big factor in understandability. In GT it may be > trivial because you can open implementors in a plane right next to the code > browser. Different toolsets themselves mean different trade offs. There are > no one size fits all answers for all time. There are principles that have > to > be negotiated with your current environment, use case, experience level, > team size... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 15, 2020