On Monday, December 27, 2004, at 11:13:37 AM, aacockburn wrote:
> I accept your comments pretty much 'as is' (even the excrable taste
> part, since you at least made is potentially symmetic ;-).
Thanks for noticing. If I can't tease you, who can? (Don't answer
that.)
> 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.
Yes, though the implementation of #value on Boolean makes it clearly
work. But you get those complaints from the compiler all the time.
Best to bow to convention, I think, though bowing isn't my usual
demeanor.
> 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 ).
Darn good point. It's hard to disagree. I suppose it's similar to
many uses of the ternary thing in C, ?: . In some usages, it's
clear, and in the rest, probably worth avoiding or at least
covering.
I have a perhaps unnatural affection for inject:into: and people
should keep an eye on me because of that.
><snip/>
> ...etc... I really like your "ifStrike: [ ... sumThreeRolls ... ]
> stuff. may try it.
Thanks. I like to try all kinds of options. To me that's part of how
to learn a language well: say things in as many ways as you can,
always trying to stay within the "style" of the language.
Smalltalk's good for that, because experiments are so easy to do.
>> 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 ...
Good story, and so true. Learning to use, not just the words of the
language, but the tools around it, makes so much difference. That's
why I love having tried so many languages, and why I support the
pragprog notion of a new language every year. They change the way
one thinks.
> Back to your point, the naming and wording should make the code
> largely 'self evident.'
Yes. So much comes down to good names. Expressing ideas, and
avoiding duplication. And tests. Tests, expressing ideas, and
avoiding duplication. And minimization. Our chief weapons are
running all the tests, avoiding duplication, expressing our ideas,
and minimizing the number of entities.
Oh damn, that's what he said, isn't it? :)
Ron Jeffries
www.XProgramming.com
Replacing an on-site customer with some use cases is about as effective
as replacing a hug from your Mom with a friendly note.
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/
