Re: [Pharo-users] is this better regarding naming thigs
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
On Sun, Jan 5, 2020, 15:51 xap <xap@router.33mail.com> wrote:
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!
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.
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
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 (<xap@router.33mail.com>) 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
"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
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 <santids97@gmail.com> 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 (<xap@router.33mail.com>) 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
participants (5)
-
Richard O'Keefe -
Richard Sargent -
Roelof Wobben -
Santiago Dandois -
xap