I accept your comments pretty much 'as is' (even the excrable taste
part, since you at least made is potentially symmetic ;-). Even after
only 3 days in the browser, I've already given in on the Boolean or:
[Block] issue, since that is obviously the Smalltalk style.
Here's my beef with inject:into: ... that snippet of code is all
about /how/ to implement your intention, and says nothing about what
your intention is. If anything deserved a comment, it would be
inject:into:, to say what the programmer had in mind while coming up
with that code. E.g.
^ collection inject: 0 into: [ :sum :each | sum + each ]
absolutely does not convey to me in the slightest that this code is
summing the values in the collection. And given how expressive all
the rest of Smalltalk is, this stands out like a sore thumb. I grit
my teeth every time I see or use it ( you can see the state of my
health, what with the stomach the teeth and the shrink all in the
act ).
There are so many cosmetic methods in Smalltalk, I can't see why a
few good idioms for inject:into: can't be shipped standard. e.g.
"aCollectionOfNumbers summed" is the above.
"aCollectionOfWhooseis summedWith: [ :item | item numericValue ]" or
"aCollectionOfWhooseis sumOver: [ :item | item numericValue ]"
for the general form.
(e.g., in adding up my checkbook, it should look something like
"balance := transactions sumOver: [ :item | item amount ]"
(I couldn't decide between summedWith: and sumOver: when modifying my
image ... I'll wait 'till I use it again to decide.)
> > Game>>framesFromRolls: rolls
> > .. | frameStart |
> > .. .. frames := OrderedCollection new.
> > .. .. frameStart := 1.
> > .. .. 10 timesRepeat: [ | frame |
> > .. .. .. frame := Frame new fromRolls: rolls at: frameStart.
> > .. .. .. frames addLast: frame.
> > .. .. .. frameStart := frameStart + frame rollsUsed.
> > .. .. ].
> > .. ^frames
>
> The above is on the hairy edge of too complex for my taste. I don't
> see how to simplify it, but my smeller would be asking me to.
>
...etc... I really like your "ifStrike: [ ... sumThreeRolls ... ]
stuff. may try it.
> Part of the skill in writing and reading Smalltalk is /not/ to
> look at all the classes, instance variables, and methods. One
> works in a way where one never really tries to grasp the 12
> methods all at once. Instead, something like
>
> self isStrike ifTrue: [^self sumThreeBalls].
> self isSpare ifTrue: [^self sumThreeBalls].
> ^self sumTwoBalls
>
Yes, completely agree, and that is a large part of it. I always find
it fascinating how the shape of our viewing/editing tools affect the
shape of our code.
I recall someone who wrote several thousand 3-line functions way back
in the 1970s, and all we had was a file system and a text editor to
work with them. We all hated him and as soon as he left, smashed
those teeny methods back into page-sized blobs so we coud 'see' what
was going on (imagine looking at a 3-line function, closing the
editor, searching in the file system to get the name (no double-click
allowed), going back to the editor, opening the next function, and
finding it is also 3 lines long, and repeating ... the Law of Demeter
neatly implemented in the wrong IDE). Used Smalltalk in the 80s,
then ran into another system implemented in the same way, and
recognized at that point the difference between viewing the teeny
functions in a decent browser and viewing the same code with file
system plus editor.
Back to your point, the naming and wording should make the code
largely 'self evident.'
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
