April 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #244: 2184-contrastingColor-and-contrastingForegroundColor-should-be-merged-and-renamed

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #244 was: SUCCESS. The Pull Request #3253 was integrated: "2184-contrastingColor-and-contrastingForegroundColor-should-be-merged-and-renamed" Pull request url: https://github.com/pharo-project/pharo/pull/3253 Issue Url: https://github.com/pharo-project/pharo/issues/2184 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 28, 2019

Re: [Pharo-dev] How to convey that a message create a new instance

by ducasse

> 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 <stepharo(a)netcourrier.com <mailto: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(a)gmail.com <mailto: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

April 28, 2019

Re: [Pharo-dev] How to convey that a message create a new instance

by Nicolas Anquetil

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 <stepharo(a)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(a)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

April 28, 2019

Re: [Pharo-dev] How to convey that a message create a new instance

by ducasse

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 <g.cotelli(a)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 > > On Sat, Apr 27, 2019, 14:27 ducasse <stepharo(a)netcourrier.com <mailto: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 >

April 28, 2019

Re: [Pharo-dev] How to convey that a message create a new instance

by Ben Coman

> On Sat, Apr 27, 2019, 14:27 ducasse <stepharo(a)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(a)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

April 28, 2019

Re: [Pharo-dev] How to convey that a message create a new instance

by Gabriel Cotelli

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 <stepharo(a)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 > >

April 27, 2019

How to convey that a message create a new instance

by ducasse

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

April 27, 2019

[Pharo 8.0] Build #243: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #243 was: SUCCESS. Could not extract further issue information from commit message: Update minimum-reviews.yml make changesThreshold 1... 100 is far too high as most changes are very small Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #242: 3225-RGPackage-should-be-RGPackageDefinition

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #242 was: SUCCESS. The Pull Request #3226 was integrated: "3225-RGPackage-should-be-RGPackageDefinition" Pull request url: https://github.com/pharo-project/pharo/pull/3226 Issue Url: https://github.com/pharo-project/pharo/issues/3225 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #241: 3239-CDNode-protocols-look-totally-broken

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #241 was: SUCCESS. The Pull Request #3249 was integrated: "3239-CDNode-protocols-look-totally-broken" Pull request url: https://github.com/pharo-project/pharo/pull/3249 Issue Url: https://github.com/pharo-project/pharo/issues/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019