On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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
I agree with the above
Yes but :) Take two minutes to look at the Color API. Because I use this when I design my class. Now Color has also a nice API such Color red darker Most of the time the methods are returning a new object. So using as would be strange Color red asDarker. Color read asMuchLighter Why not I would like to address first all the methods that look like doing side effect but not doing them.
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