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