#beBetween:and:
+1. Goes nicely with `(x beBetween: y and: z) between: y and: z` being always true. Peter On Sat, Apr 21, 2018 at 11:56 AM, PBKResearch <peter@pbkresearch.co.uk> wrote:
Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the following:
destX := destX asInteger
min: maxVal
max: minVal.
Which seems to summarize the illogicality very well.
However, note that PetitParser, PetitParser2 and Magritte all implement #min:max: as a method to set upper and lower limits, and there the meaning is the logical one. It all looks a mess.
Peter Kenny
*From:* Pharo-users <pharo-users-bounces@lists.pharo.org> *On Behalf Of *Ben Coman *Sent:* 21 April 2018 02:16 *To:* Any question about pharo is welcome <pharo-users@lists.pharo.org>; The general-purpose Squeak developers list <squeak-dev@lists. squeakfoundation.org> *Subject:* Re: [Pharo-users] min:max:
On 21 April 2018 at 03:51, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
Out of curiosity.
I always found the #min:max: confusing and lost in its expressiveness.
One should write:
10 min: 48 max: 12
to expect 12.
but logically one (at least me) may want to express it as:
10 min: 12 max: 48
Then when reading its source code, it is even more confusing:
min: aMin max: aMax ^ (self min: aMin) max: aMax
Are not the argument names inversed in their meaning, if any?
I would agree. I see most use by Color like...
Color>>adjustBrightness: brightness
"Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)"
^ self class
h: self hue
s: self saturation
v: (self brightness + brightness min: 1.0 max: 0.005)
alpha: self alpha
Trying to read that twists my brain.
I can understand the intent from the implementation
min: aMin max: aMax
^ (self min: aMin) max: aMax
but that message might more properly be #min:thenMax:
However something like
(self brightness + brightness boundedBy: 0.005 and: 1.0)
(self brightness + brightness boundedMin: 0.005 max: 1.0)
seems more intention revealing.
Altering #min:max semantics would make awful portability,
but perhaps it should forward to a new method to make it clear the other is preferred.
Would the Squeak community be amenable to a similar change?
I'd be happy to contribute the changes to the Squeak Inbox.
cheers -ben