On Sat, 21 Apr 2018, Ben Coman wrote:

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.