Hello
In a earlier question I get a remark to think better about naming things. Now I did a challene where I have to find anagrams of a given word in a collection, So I did this : findAnagramsCandidates: aCollection subject: aWord | charBag | charBag := aWord asLowercase asBag. ^ aCollection reject: [ :word | (word sameAs: aWord) or: [ word asLowercase asBag ~= charBag ] ] is my naming here better or can i improved and if so how ? Regards, Roelof |
> On 5 Jan 2020, at 15:06, Roelof Wobben via Pharo-users <[hidden email]> wrote: > > > From: Roelof Wobben <[hidden email]> > Subject: is this better regarding naming thigs > Date: 5 January 2020 at 15:06:18 GMT+1 > To: Any question about pharo is welcome <[hidden email]> > > > Hello > > In a earlier question I get a remark to think better about naming things. > Now I did a challene where I have to find anagrams of a given word in a collection, > > So I did this : > > findAnagramsCandidates: aCollection subject: aWord > | charBag | > charBag := aWord asLowercase asBag. > ^ aCollection > reject: > [ :word | (word sameAs: aWord) or: [ word asLowercase asBag ~= charBag ] ] > > > is my naming here better or can i improved and if so how ? It is good. Possible alternatives: aCollectionOfWords instead of aCollection, I would even dare to use words/wordsCollection and word, since I am not a big fan of the 'a' and 'an' prefixes. Also the argument to the reject block is often called each or eachWord, but this is more of a tradition, word is OK too (but it would then conflict with naming the argument word). > Regards, > > Roelof > > > > |
In reply to this post by Pharo Smalltalk Users mailing list
hi, I'm just starting out w/ pharo and have a question re your code;
specifically, in reject: [ :word | (word sameAs: aWord) or: [ word asLowercase asBag ~= charBag ] ] is that inner block needed? would it be less smalltalk-esque to write, say: reject: [ :w | (w = aWord) or: (w asLowercase asBag ~= charBag) ] thx! separately recently I watched an alan kay interview in which he says an oo program is typically much smaller than its imperative counterpart and i wondered why. Well, it seems that reduction comes from the language/system providing a zillion methods -- asBag, here -- one would otherwise need to implement, oneself :) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Administrator
|
On Sun, Jan 5, 2020, 15:51 xap <[hidden email]> wrote: hi, I'm just starting out w/ pharo and have a question re your code; The answer to your question is provided by looking at the definition of the #or: message. Specifically, look on the class Boolean and its subclasses. They should tell you what kinds of objects are allowed for the argument. There is also an #| message which does what you have asked the #or: message to do. Study the differences in their definitions in the Boolean hierarchy.
|
thx Rixhard. looks like or: takes an 'alternativeBlock', i.e. a block.
however substituting a parenthesized expression (or what i assume is one) as I did before, in place of the inner block, w/ no other changes has the method continue to work as expected, hence my question. *shrug* i need to rtfm :-/ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
It's better (conceptually and in performance) to use the inner block, but is not always necessary. The #or: message sends the `value` message to it's collaborator if the bolean is false. Blocks responds to value executing theirs code, but all objects respond to value since it's defined in the Object class as ^self. Therefore, the result is the same but the messages involved and the order in which they are being sent are not. In performance, for the case where the first bolean was true, is better the one with the surrounding block , since the code inside it is never being executed. You should really try both versions with the debugger to see it by yourself. Cheers, Santiago Dandois El dom., 5 ene. 2020 a las 19:53, xap (<[hidden email]>) escribió: thx Rixhard. looks like or: takes an 'alternativeBlock', i.e. a block. |
"but all objects respond to value..."; thx, Santiago -- that makes more
sense, that or: cares only about its receiver/argument evaluable as a Boolean, no matter they started as blocks, expressions, or something else (makes me wonder if a bare-value is a degenerate case of a block ... but don't mind me, I'm just talking aloud). separately, point taken re expressions being evaluated, and blocks possibly not. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Hello,
Nice to see that someone who ask another question on my question but do i get a answer on my question too. So if the naming is better now. Roelof Op 6-1-2020 om 02:18 schreef xap: > "but all objects respond to value..."; thx, Santiago -- that makes more > sense, that or: cares only about its receiver/argument evaluable as a > Boolean, no matter they started as blocks, expressions, or something else > (makes me wonder if a bare-value is a degenerate case of a block ... but > don't mind me, I'm just talking aloud). separately, point taken re > expressions being evaluated, and blocks possibly not. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > |
hi Roelof, i didn't mean to hijack your thread, sorry -- my question was
directed at you, then kinda took on a life of its own. That said, Sven had/has responded to your op (original post), no? One additional change I would make: rename "findAnagramsCandidates" --> "findAnagrams" : it's shorter, and possibly more correct since what's returned are true anagrams rather than candidates-that-may-be-anagrams ? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Op 6-1-2020 om 09:34 schreef xap:
> hi Roelof, i didn't mean to hijack your thread, sorry -- my question was > directed at you, then kinda took on a life of its own. > > That said, Sven had/has responded to your op (original post), no? > > One additional change I would make: rename "findAnagramsCandidates" --> > "findAnagrams" : it's shorter, and possibly more correct since what's > returned are true anagrams rather than candidates-that-may-be-anagrams ? > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > NP, And if my question was answered , I miss it. That name was given by the challenge so if I would change it, Im afraid that I also have to change all tests included by the challenge. But thanks for answering. Roelof |
Here's the permalink to Sven's response (in case it still isn't visible to
you): http://forum.world.st/is-this-better-regarding-naming-thigs-tp5109389p5109392.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Thanks.
I have missed that one. Thanks for pointing it to me. Roelof Op 6-1-2020 om 13:13 schreef xap: > Here's the permalink to Sven's response (in case it still isn't visible to > you): > http://forum.world.st/is-this-better-regarding-naming-thigs-tp5109389p5109392.html > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > |
In reply to this post by Pharo Smalltalk Users mailing list
What is the receiver? There are two and only two relevant objects:
the word and the collection. aCollection selectAnagramsOf: aString aString anagramsIn: aCollection would be good names. In a language that did not let you extend system classes, anagrams(of: aString, in: aCollection) would be good, but Smalltalk is not such a language. 'findAnagramsCandidates:subject:' is intention-revealing, but is not good English. Well, maybe the intentions could be revealed a bit better. What is the subject of an anagram? No idea. What is an 'anagramsCandidate'? No idea. What is the difference between an 'anagram' and an 'anagramCandidate'? <whatever> anagramsOf: aString in: aCollection <whatever> selectFrom: aCollection anagramsOf: aString On Mon, 6 Jan 2020 at 03:07, Roelof Wobben via Pharo-users <[hidden email]> wrote: > > Hello > > In a earlier question I get a remark to think better about naming things. > Now I did a challene where I have to find anagrams of a given word in a > collection, > > So I did this : > > findAnagramsCandidates: aCollection subject: aWord > | charBag | > charBag := aWord asLowercase asBag. > ^ aCollection > reject: > [ :word | (word sameAs: aWord) or: [ word asLowercase asBag > ~= charBag ] ] > > > is my naming here better or can i improved and if so how ? > > Regards, > > Roelof > > |
In reply to this post by Santiago Dandois
I've always considered "all objects respond to #value" as a bug.
It certainly is not portable: it wasn't in Smalltalk-80, or Apple Smalltalk, or ANSI Smalltalk, and it isn't in GNU Smalltalk or Dolphin Smalltalk or VisualWorks. It's a peculiarity of Squeak/Pharo and Smalltalk/X. This is a misfeature that can hide bugs until they are ready to hurt you. On Mon, 6 Jan 2020 at 12:13, Santiago Dandois <[hidden email]> wrote: > > It's better (conceptually and in performance) to use the inner block, but is not always necessary. The #or: message sends the `value` message to it's collaborator if the bolean is false. Blocks responds to value executing theirs code, but all objects respond to value since it's defined in the Object class as ^self. Therefore, the result is the same but the messages involved and the order in which they are being sent are not. In performance, for the case where the first bolean was true, is better the one with the surrounding block , since the code inside it is never being executed. > > You should really try both versions with the debugger to see it by yourself. > > Cheers, > Santiago Dandois > > El dom., 5 ene. 2020 a las 19:53, xap (<[hidden email]>) escribió: >> >> thx Rixhard. looks like or: takes an 'alternativeBlock', i.e. a block. >> however substituting a parenthesized expression (or what i assume is one) as >> I did before, in place of the inner block, w/ no other changes has the >> method continue to work as expected, hence my question. *shrug* i need to >> rtfm :-/ >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> |
In reply to this post by Richard O'Keefe
When I wrote "is not good English", I meant that "findAnagramsCandidates"
sounds *horrible* to this native speaker of English. "findCandidateAnagrams" works. On Tue, 7 Jan 2020 at 18:12, Richard O'Keefe <[hidden email]> wrote: > > What is the receiver? There are two and only two relevant objects: > the word and the collection. > aCollection selectAnagramsOf: aString > aString anagramsIn: aCollection > would be good names. In a language that did not let you extend system classes, > anagrams(of: aString, in: aCollection) > would be good, but Smalltalk is not such a language. > > 'findAnagramsCandidates:subject:' is intention-revealing, but is not > good English. > Well, maybe the intentions could be revealed a bit better. > What is the subject of an anagram? No idea. > What is an 'anagramsCandidate'? No idea. > What is the difference between an 'anagram' and an 'anagramCandidate'? > > <whatever> anagramsOf: aString in: aCollection > <whatever> selectFrom: aCollection anagramsOf: aString > > > On Mon, 6 Jan 2020 at 03:07, Roelof Wobben via Pharo-users > <[hidden email]> wrote: > > > > Hello > > > > In a earlier question I get a remark to think better about naming things. > > Now I did a challene where I have to find anagrams of a given word in a > > collection, > > > > So I did this : > > > > findAnagramsCandidates: aCollection subject: aWord > > | charBag | > > charBag := aWord asLowercase asBag. > > ^ aCollection > > reject: > > [ :word | (word sameAs: aWord) or: [ word asLowercase asBag > > ~= charBag ] ] > > > > > > is my naming here better or can i improved and if so how ? > > > > Regards, > > > > Roelof > > > > |
richard, fwiw Roeloff mentioned earlier that the message-name was provided by
the exercise set he's following, and isn't of his invention: http://forum.world.st/is-this-better-regarding-naming-thigs-tp5109389p5109471.html . he sh/could fwd your note/s to the course-author ;) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
I should have remembered that, seeing that I've done 41/42 of the
Pharo exercisms, and am currently doing the F# ones in my spare time, which I have had very little of lately. I have started using the <BADNAME[: 'reason']> annotation in such cases to remind me not to fix the code. Looking back at my solution, I see that my irritation at yet another "Pharo" exercism that had no significant connection with *OOP* as such masked the irritation I should have felt at the bad name. I also recall now my annoyance at exercism.io's frequent practice of omitting key parts of specifications but including tests for them. Seriously, sometimes it's worth it to write good code and then write glue code to the required interface. On Tue, 7 Jan 2020 at 18:50, xap <[hidden email]> wrote: > > richard, fwiw Roeloff mentioned earlier that the message-name was provided by > the exercise set he's following, and isn't of his invention: > http://forum.world.st/is-this-better-regarding-naming-thigs-tp5109389p5109471.html > . he sh/could fwd your note/s to the course-author ;) > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
Richard O'Keefe wrote
> Seriously, sometimes it's worth it to write good code and then write > glue code to the required interface. Maybe "most of the time". Or "It's almost always worth it". Why practice bad habits? We should reinforce writing good code -- there's not enough of it out there. There's another advantage to this advice: It would be good practice with the techniques needed to extend or interface to existing codebases. We aren't going to rewrite such existing code, and we generally can't rewrite its interfaces either. So, write good code and then write glue code to the required interface. Seems to me this should be standard practice. And the exercism.io mentors might take this into account... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Free forum by Nabble | Edit this page |