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