> On 13 Sep 2019, at 20:52, Tim Mackinnon <[email protected]> wrote:
>
>
> I agree with Ben’s reaction below , however the point that ? ! could be
> repurposed for something if they weren’t special characters is a good one.
> Maybe there are other usages we are missing, and that’s the point I guess.
Exactly.
I think that it would be nice to think a bit.
I like the idea that I do not have to read the code to understand if a method
is a predicate.
odd?
even?
Stef
>
> Tim
>
> Sent from my iPhone
>
> On 13 Sep 2019, at 17:41, Ben Coman <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>
>> On Wed, 11 Sep 2019 at 15:10, ducasse <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> > On 11 Sep 2019, at 04:07, James Foster <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > Would use of ? and ! in unary/keyword selectors be convention or somehow
>> > required? If simply convention, then we should start with renaming testing
>> > methods to be named is* or has*.
>> > flag1 := anInteger even. “not good"
>>
>> Agreed. That could "almost" be construed as converting a 3 to a 2 or 4.
>>
>>
>> > flag2 := anInteger isEven. “better"
>>
>> Agreed. It reads well.
>>
>>
>> > flag3 := anInteger even?. “how much better?”
>>
>> For me, this doesn't read as well as flag2, but even though there is some
>> redundancy, for me a combination reads well...
>> flag3a := anInteger isEven?
>> Perhaps if "?"==>Boolean was a strong convention then there could be a check
>> when the value is returned rather than when it is used (or would that
>> complicate other things?)
>>
>>
>> > flag4 := #(1 2 3) includes?: 2. “how much better?”
>>
>> My first impression is "yuck!", but then I think... "maybe" if there was a
>> definite benefit (i.e. optimization) from strong guarantees about the return
>> value being Boolean.
>>
>>
>>
>> I think that I would use ? mainly for unary message
>>
>> Now I’m sure that if you look carefully some people use
>>
>> include
>> for the action
>> includes
>> for the tests
>>
>> I took include as an example and this is super not intention revealing.
>>
>> >> lineUpBlockBrackets
>>
>> lineUpBlockBrackets?
>> Now I will rewrite them all as shouldLineUpBlockBrackets or
>> isLineUpBlockBrackets and to me for unary message ? makes it a lot better.
>>
>> btw, some alternatives...
>> doBlockBracketsLineUp - reads well but "do" is already a loaded word
>> areBlockBracketsLinedUp - reads well with the past-tense phrasing
>>
>> cheers -ben
