Hi Steph,
That remind me discussion about imperative vs functional

Yes me too. :)

Imperative sort or beSorted authorizes/convey in place modification. But not always, a Set cannot beSorted, so sort will answer an Array.

Adjective sorted convey a functional style and forbid such side effect.

So brigther and duller are perfect selectors, just make the comment more clear (answer a Color which��).

Yes this is what I was thinking.

Selector setInstVar: is clearly imperative, both name and comment are misleading. Noun instVar: is also expected to be such setter.

For adjust, i don't know: first, i'd expect the argument to be an adjustment, like +0.1 or -0.2, not direct a brightness value. brightness: would be a setter, and withBrightness: a copy, adjustedBrightness: is heavy style...
If the whole class has functional style, it might be understood as functional. Think of select: reject: collect:.

Not a totally satisfying answer I think��

we are thinking the same.

I will digest it.

Now I��m fixing our poor friend the recentMessageList. Soon back at work and also our lovely emergency evaluator

Because it is useful when you try like me TDD when hacking keystroke main loop :)

Stef

On 28 Apr 2019, at 01:05, Gabriel Cotelli <g.cotelli@gmail.com> wrote:

I tend to use the following idioms:
- 'beSomething' idiom for cases modifying the receiver.
- 'asSomething' can or cannot return a new object
- 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance

On Sat, Apr 27, 2019, 14:27 ducasse <stepharo@netcourrier.com> wrote:
Hi

I was looking at the API of Color and it is really confusing to me and wrong
For example beOpaque

beOpaque
  "Set the transparency of the receiver to opaque, i.e. alpha to 1.0."

  ^ self alpha: 1.0

But

alpha: aFloat
  "Answer a new Color with the given amount of opacity ('alpha')."

  ^ self class r: self red g: self green b: self blue alpha: aFloat

Or

adjustBrightness: brightness
  "Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)��

  but this creates a new color.

I would really like to see how we can improve the fact that reading the method selector should
let us understand whether a message is modifying or not the receiver.

Since many methods such as darker, duller,��. do not show that they return a new instance but actually do it.
May be we can make sure that modifying receiver methods are much better identified as doing so.

beOpaque -> asOpaque
adjustBrightness: -> colorWithBrigthness:

Do you have any better ideas?

Stef