> a negative | (b between: c and: d)
> ifTrue: [a := c negated]
> As a reader, you should be able to tell that “a” is sent message “negative” (no parameters) which comes back true or false; “b” is sent message “between: c and: d” which also returns true or false. The results are ORed together to become the receiver for the “ifTrue: [a := c negated]” message.
When messages are sent to boolean values, the language is harder to read.
Earlier in that into we were told that the first argument's preposition is always fused with the name of the method/message/operation, while subsequent prepositions aren't thus fused. That also makes the language hard to read.
We are given examples of methods/functions which are adjectives, e.g. "negated", while others are verbs in the imperative voice, e.g. "make", "rotate" etc. That also makes the language (or its idiomatic use) harder to read.
> As a reader, you should be able to tell that “a” is sent message “negative” (no parameters) which comes back true or false; “b” is sent message “between: c and: d” which also returns true or false. The results are ORed together to become the receiver for the “ifTrue: [a := c negated]” message.
When messages are sent to boolean values, the language is harder to read.
Earlier in that into we were told that the first argument's preposition is always fused with the name of the method/message/operation, while subsequent prepositions aren't thus fused. That also makes the language hard to read.
We are given examples of methods/functions which are adjectives, e.g. "negated", while others are verbs in the imperative voice, e.g. "make", "rotate" etc. That also makes the language (or its idiomatic use) harder to read.