- Pharo-users - lists.pharo.org

Re: how can I improve this

by HernÃ¡n Morales Durand

Hi Roelof, Maybe something like this: String>>hammingDistanceTo: aString " Answer the amount of substitutions between the receiver and aString. Both must be of equal length " ^ (1 to: self size) count: [ : i | (self at: i) ~= (aString at: i) ] El lun., 14 sept. 2020 a las 16:15, Roelof Wobben via Pharo-users (< pharo-users(a)lists.pharo.org>) escribiÃ³: > Hello, > > I have solved the hamming challenge of exercism where I have to find in > how many places two strings are different. > > my solution is : > > distanceStrand1: aString strand2: aString2 > aString size == aString2 size > ifFalse: [ DomainError signal: (self messageFor: aString > strand2: aString2) ]. > ^ (1 to: aString size) > sumNumbers: [ :index | > (aString at: index) == (aString2 at: index) > ifTrue: [ 0 ] > ifFalse: [ 1 ] ] > > > messageFor: aString strand2: aString2 > aString notEmpty & aString2 notEmpty > ifTrue: [ ^ 'left and right strands must be of equal length' ]. > aString ifEmpty: [ ^ 'left strand must not be empty' ]. > ^ 'right strand must not be empty' > > > Can this be improved? > > Roelof >

Sept. 14, 2020

how can I improve this

by Roelof Wobben

Hello, I have solved the hamming challenge of exercism where I have to find in how many places two strings are different. my solution is : distanceStrand1: aString strand2: aString2 Â Â Â aString size == aString2 size Â Â Â Â Â Â ifFalse: [ DomainError signal: (self messageFor: aString strand2: aString2) ]. Â Â Â ^ (1 to: aString size) Â Â Â Â Â Â sumNumbers: [ :index | Â Â Â Â Â Â Â Â Â (aString at: index) == (aString2 at: index) Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ 0 ] Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ 1 ] ] messageFor: aString strand2: aString2 Â Â Â aString notEmpty & aString2 notEmpty Â Â Â Â Â Â ifTrue: [ ^ 'left and right strands must be of equal length' ]. Â Â Â aString ifEmpty: [ ^ 'left strand must not be empty' ]. Â Â Â ^ 'right strand must not be empty' Can this be improved? Roelof

Sept. 14, 2020

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

by Marcus Denker

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> 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 >> >

Sept. 14, 2020

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

by Marcus Denker

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> 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 >

Sept. 14, 2020

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

by Sean P. DeNigris

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 :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 14, 2020

Re: How can I make this more OOP

by Sean P. DeNigris

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. 14, 2020

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

by Marcus Denker

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

Sept. 14, 2020

Re: [Pharo-users] How can I make this more OOP

by Roelof Wobben

Sept. 14, 2020

Re: [Pharo-users] How can I make this more OOP

by 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 > > >

Sept. 14, 2020

Re: [Pharo-users] How can I make this more OOP

by Noury Bouraqadi

Your own methods can be added to any class. Just ensure they are introduced as class extensions attached to your project's package. Use the checkbox at the bottom of the system browser. > On 13 Sep 2020, at 16:44, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > > > -------- Doorgestuurd bericht -------- > Onderwerp: Re: [Pharo-users] How can I make this more OOP > Datum: Sun, 13 Sep 2020 16:43:59 +0200 > Van: Roelof Wobben <r.wobben(a)home.nl> <mailto:r.wobben@home.nl> > Aan: Noury Bouraqadi <bouraqadi(a)gmail.com> <mailto:bouraqadi@gmail.com> > > Hello, Noury, > > Thanks for letting me see this but I wonder if it is good practice to place my own methods on the Object and UndefinedObject ? > > Roelof > > > Op 13-9-2020 om 14:51 schreef Noury Bouraqadi: >> Hi Roelof, >> >> Polymorphism is the answer. >> >> Object >> flattenInto: result >> result nextPut: anObject >> >> UndefinedObject >> flattenInto: result >> ^self >> >> Collection >> flattenInto: result >> self do: [ :item | item flattenInto: result ] >> >> flatten: anObject >> ^ (OrderedCollection streamContents: [ :stream | anObject flattenInto: stream ]) asArray >> >> Noury >> >> >

Sept. 14, 2020