> 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
>>
On Sun, 28 Apr 2019 at 07:06, 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
This indicates some type of conversion which naturally must be a
different object,
so for consistency it would be nice to be able to consider this always
returns a new object,
except that...
s := 'abcd'.
s == s asString.
==> true
Maybe it *should* return a copy, but thats fairly pervasive in the
system and maybe subtly relied on.
cheers -ben
Hi Ben,
Why this expectation?
If i'm already a String, I rather have the right to be lazy.
The selector is not asNewString.