Smalltalk › Squeak › Squeak - Dev

Re: [Pharo-users] min:max:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Ben Coman

Re: [Pharo-users] min:max:

On 21 April 2018 at 03:51, Hilaire <[hidden email]> 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

HilaireFernandes

Re: [Pharo-users] min:max:

Le 21/04/2018 à 03:16, Ben Coman a écrit :
>
> 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.
>

Indeed, and it is probably a no go.
However an unbreak change could be to just twist the argument name as:

min: aMax max: aMin
^ (self min: aMax) max: aMin

At least when reading the source code, the intention is clearer.

I am comfort to not be the only one to have his brain twisted when
reading this method uses.

Hilaire

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Levente Uzonyi

Re: [Pharo-users] min:max:

In reply to this post by Ben Coman

Squeak has #clampLow:high: for this reason.

Levente

On Sat, 21 Apr 2018, Ben Coman wrote:

>
>
> On 21 April 2018 at 03:51, Hilaire <[hidden email]> 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
>
>

Ben Coman

Re: [Pharo-users] min:max:

On Sat, 21 Apr 2018, Ben Coman wrote:

On 21 April 2018 at 03:51, Hilaire <[hidden email]> 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.

On 21 April 2018 at 17:56, Levente Uzonyi <[hidden email]> wrote:

Squeak has #clampLow:high: for this reason.

Thanks Levente. Thats a good one.

With similar usage clamping signals in electronics, this is worthwhile to adopt.

https://pharo.fogbugz.com/f/cases/21758/Replace-min-max-with-clampLow-High

cheers -ben