Stef

For example in the past, Gnome File browser used to have the idea of "emblems" that were added to icons to show a "cross cutting property"

<Image-KP7U0Z.png>

nicolas

On Sun, 2019-04-28 at 10:56 +0800, Ben Coman wrote:
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
--
Nicolas Anquetil
RMod team -- Inria Lille