Le dim. 28 avr. 2019 �� 08:43, ducasse <stepharo@netcourrier.com> a ��crit��:

Tx I��m doing the same.��
Now may be we should revisit the API of color to at least convert the method indicating side effect but lying��
to convey that they are functional.��

beOpaque
-> asOpaque

adjustBrightness:

may copyWithBrightness: (I��m not really fan of it).��

or may be asWithAdjustedBrightness:��

I will have to brainstorm more.��

Tx for the discussion
Tx Ben too.��

Hi Steph,

That remind me discussion about imperative vs functional

��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...).

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...

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