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? Hilaire -- Dr. Geo http://drgeo.eu
A name like this would be clearer (although much more annoying): returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48 Thanks, cbc On Fri, Apr 20, 2018 at 12:51 PM, 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?
Hilaire
-- Dr. Geo http://drgeo.eu
On April 21, 2018 12:12:10 AM GMT+02:00, Chris Cunningham <cunningham.cb@gmail.com> wrote:
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
#beBetween:and: or #boundedBetween:and:
Thanks, cbc
On Fri, Apr 20, 2018 at 12:51 PM, 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?
Hilaire
-- Dr. Geo http://drgeo.eu
Oh yes!!!! On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <cunningham.cb@gmail.com> wrote:
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
Thanks, cbc
On Fri, Apr 20, 2018 at 12:51 PM, 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?
Hilaire
-- Dr. Geo http://drgeo.eu
On 21 Apr 2018, at 15:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Oh yes!!!!
On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <cunningham.cb@gmail.com> wrote:
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
why 'return' ? most methods return something. 10 atLeast: 12 butNoMoreThan: 48
Thanks, cbc
On Fri, Apr 20, 2018 at 12:51 PM, 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?
Hilaire
-- Dr. Geo http://drgeo.eu
Yes :) On Sat, Apr 21, 2018 at 4:21 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 21 Apr 2018, at 15:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Oh yes!!!!
On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <cunningham.cb@gmail.com> wrote:
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
why 'return' ? most methods return something.
10 atLeast: 12 butNoMoreThan: 48
Thanks, cbc
On Fri, Apr 20, 2018 at 12:51 PM, 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?
Hilaire
-- Dr. Geo http://drgeo.eu
The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones. Le 21/04/2018 à 00:12, Chris Cunningham a écrit :
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue   10 returnAtLeast: 12 butNoMoreThan: 48
-- Dr. Geo http://drgeo.eu
I can find no reference to #min:max: in Dolphin X6.1. Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of Hilaire Sent: 21 April 2018 17:36 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] min:max: The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones. Le 21/04/2018 à 00:12, Chris Cunningham a écrit :
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
-- Dr. Geo http://drgeo.eu
On 22 April 2018 at 05:59, PBKResearch <peter@pbkresearch.co.uk> wrote:
I can find no reference to #min:max: in Dolphin X6.1.
Peter Kenny
-----Original Message----- From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of Hilaire Sent: 21 April 2018 17:36 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] min:max:
The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones.
Le 21/04/2018 à 00:12, Chris Cunningham a écrit :
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
-- Dr. Geo http://drgeo.eu
Smalltalk/X has both #min:max: and #clampBetween:and: in its Magnitude.st. Dolphin 7 has neither. The definition of #clampBetween:and: in ST/X is clampBetween: min and: max max < self ifTrue: [^max]. self < min ifTrue: [^min]. ^self I've deleted the comment because it doesn't help with the question "what is the CONTRACT for this method?" In particular, you would naturally expect from the name that (x clampBetween: y and: z) between: y and: z Example: 3 clampBetween: 2 and: 1 ==> 1 1 between: 2 and: 1 ==> false On 22 April 2018 at 04:35, Hilaire <hilaire@drgeo.eu> wrote:
The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones.
Le 21/04/2018 à 00:12, Chris Cunningham a écrit :
A name like this would be clearer (although much more annoying):
returnAtLeast: minValue butNoMoreThan: maxValue 10 returnAtLeast: 12 butNoMoreThan: 48
-- Dr. Geo http://drgeo.eu
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
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 <mailto: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
#beBetween:and:
+1. Goes nicely with `(x beBetween: y and: z) between: y and: z` being always true. Peter On Sat, Apr 21, 2018 at 11:56 AM, PBKResearch <peter@pbkresearch.co.uk> wrote:
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
On Fri, Apr 20, 2018 at 9:51 PM, 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
I do not understand the result :) To me this method is illnamed.
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?
Hilaire
-- Dr. Geo http://drgeo.eu
participants (9)
-
Ben Coman -
Chris Cunningham -
herby＠mailbox.sk -
Hilaire -
PBKResearch -
Peter Uhnák -
Richard O'Keefe -
Stephane Ducasse -
Sven Van Caekenberghe