Smalltalk › Pharo › Pharo Smalltalk Developers

How to convey that a message create a new instance

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

ducasse

How to convey that a message create a new instance

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

gcotelli

Re: How to convey that a message create a new instance

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 <[hidden email]> 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

Ben Coman

Re: How to convey that a message create a new instance

> On Sat, Apr 27, 2019, 14:27 ducasse <[hidden email]> 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 <[hidden email]> 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

ducasse

Re: How to convey that a message create a new instance

In reply to this post by gcotelli

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.

On 28 Apr 2019, at 01:05, Gabriel Cotelli <[hidden email]> 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 <[hidden email]> 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

Nicolas Anquetil

Re: How to convey that a message create a new instance

In reply to this post by Ben Coman

maybe the editor could detect them and put a special sign on them.

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"

nicolas

On Sun, 2019-04-28 at 10:56 +0800, Ben Coman wrote:

On Sat, Apr 27, 2019, 14:27 ducasse <[hidden email]> 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 <[hidden email]> 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

ducasse

Re: How to convey that a message create a new instance

maybe the editor could detect them and put a special sign on them.

It requires some static analysis. It is possible :)

But I would like to find a solution at the selector level.

What you suggest could be a nice master topics :)

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 <[hidden email]> 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 <[hidden email]> 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

Nicolas Cellier

Re: How to convey that a message create a new instance

In reply to this post by Ben Coman

Le dim. 28 avr. 2019 à 04:57, Ben Coman <[hidden email]> a écrit :

> On Sat, Apr 27, 2019, 14:27 ducasse <[hidden email]> 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 <[hidden email]> 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.

ducasse

Re: How to convey that a message create a new instance

Now we want to have readonly strings but it will be for Pharo 90 probably.

This will also help the VM.

Stef

On 28 Apr 2019, at 10:36, Nicolas Cellier <[hidden email]> wrote:

Le dim. 28 avr. 2019 à 04:57, Ben Coman <[hidden email]> a écrit :
> On Sat, Apr 27, 2019, 14:27 ducasse <[hidden email]> 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 <[hidden email]> 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.

Sven Van Caekenberghe-2

Re: How to convey that a message create a new instance

In reply to this post by gcotelli

> On 28 Apr 2019, at 01:05, Gabriel Cotelli <[hidden email]> 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

> On Sat, Apr 27, 2019, 14:27 ducasse <[hidden email]> 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
>

ducasse

Re: How to convey that a message create a new instance

> On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>
>> On 28 Apr 2019, at 01:05, Gabriel Cotelli <[hidden email]> 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 <[hidden email]> 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
>>
>
>

Nicolas Cellier

Re: How to convey that a message create a new instance

In reply to this post by ducasse

Le dim. 28 avr. 2019 à 08:43, ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

ducasse

Re: How to convey that a message create a new instance

Hi Steph,
That remind me discussion about imperative vs functional

Yes me too. :)

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

Yes this is what I was thinking.

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…

we are thinking the same.

I will digest it.

Now I’m fixing our poor friend the recentMessageList. Soon back at work and also our lovely emergency evaluator

Because it is useful when you try like me TDD when hacking keystroke main loop :)

Stef

On 28 Apr 2019, at 01:05, Gabriel Cotelli <[hidden email]> 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 <[hidden email]> 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

Esteban A. Maringolo

Re: How to convey that a message create a new instance

In reply to this post by ducasse

Esteban A. Maringolo

On Sun, Apr 28, 2019 at 6:02 AM ducasse <[hidden email]> wrote:
> > On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <[hidden email]> wrote:
> >> On 28 Apr 2019, at 01:05, Gabriel Cotelli <[hidden email]> wrote:
> >>
> >> I tend to use the following idioms:
> >> - 'beSomething' idiom for cases modifying the receiver.
> >> - 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance
> >
> > I agree with the above

Me too.

> >> - 'asSomething' can or cannot return a new object

Only if the receiver is an instance of Something, otherwise it should
always return a new instance.

> 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

(*) I wouldn't use #asOpaque or #asDarker unless there is an Opaque or
Darker class in the system. To me "as" prefix implies "casting".

> Why not
> I would like to address first all the methods that look like doing side effect but not doing them.

#darker and #muchLighter are good enough selectors, they don't imply
returning a new object, but neither does Date>>#addDays: .

The #new and #copy prefixes are too verbose in most cases, and I don't
know a good "naming practice" related with this (selectors that return
a new instance), so if there is consistency in the class that most
selectors return a new instance even "offending" methods such as
DateAndTime>>#offset: are not harmful if consistent.

E.g. in collection I'd expect #sort to sort receiver, and #sorted to
return a new instance.
So the rule might be in the conjugation of the the selector.

So using the Color selector I would do:

Color>>#darken (verb) or Color>>#beDarker (verb)
"Makes receiver darker."

Color>>#darker (adjective)
"Returns a darker copy of receiver."

Color>>#beOpaque (verb) or Color>>opacity: (noun)
"Makes receiver darker."

Color>>#opaque (adjective)
"Returns an opaque copy of receiver."

Regards,