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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180421/3fa7d45f/attachment.html>