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.

Tim

Sent from my iPhone

> On 13 Sep 2019, at 17:41, Ben Coman <[email protected]> wrote:
> 
> 
> 
>> On Wed, 11 Sep 2019 at 15:10, ducasse <[email protected]> wrote:
>> 
>> 
>> > On 11 Sep 2019, at 04:07, James Foster <[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

Reply via email to