> 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