Squeak has #clampLow:high: for this reason.

Levente

On Sat, 21 Apr 2018, Ben Coman wrote:

> 
> 
> On 21 April 2018 at 03:51, Hilaire <hilaire at 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
> 
>