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