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

[Pharo 8.0] Build #248: 3272-Slot-Demo-HistorySlot

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

There is a new Pharo build available! The status of the build #248 was: SUCCESS. The Pull Request #3273 was integrated: "3272-Slot-Demo-HistorySlot" Pull request url: https://github.com/pharo-project/pharo/pull/3273 Issue Url: https://github.com/pharo-project/pharo/issues/3272 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 30, 2019

Re: [Pharo-dev] how implement isAbstract?

by Ben Coman

On Mon, 29 Apr 2019 at 22:38, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > A class is abstract by design and not necessarily because I can compute > something from its implementation that tells me that maybe it is abstract. > I somehow mark a class as abstract because it is abstract, not the other > way around. > Randon idea... ``#Frame abstract`` returning a hypothetical instance of AbstractClassSymbol which double-dispatches to set a property of the class when it is created per... Object subclass: #Frame abstract instanceVariableNames: 'frameNumber frameRolls nextFrame' classVariableNames: '' package: 'Exercism-Bowling' cheers -ben

April 30, 2019

Re: [Pharo-dev] color protocols and marking creation methods (msg 1 of Pharo-dev Digest, Vol 72, Issue 23)

by Jim Sawyer

> 1. Re: How to convey that a message create a new instance > (Esteban Maringolo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Apr 2019 13:11:06 -0300 > From: Esteban Maringolo <emaringolo(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] How to convey that a message create a new > instance > Message-ID: > <CAJMgPCK1YB98CFn3KxhcDxLmoY7mYoXDboT5ZC2o7ZbL6pTYjA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Esteban A. Maringolo > > > On Sun, Apr 28, 2019 at 6:02 AM ducasse <stepharo(a)netcourrier.com> wrote: >>> On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> 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. >>>> - 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance As a class, I think of Color as a factory, answering an immutable (though not literal) propertyValue. I might tell an object with a color property to change to a different propertyValue. I would expect it to do so by changing the property (replacing the current value with anotherPropertyValue), and would not expect the propertyValue itself to mutate (thus affecting all references to said value). Red cannot be darker.Â Red is Red.Â This sortOfRed can be darker than thatSortOfRed, so if you have theColorRed you can ask it for something darker, but you cannot ask it to become darker. Therefore, Color should not have any 'be' methods or 'as' methods. It might well have some fancy 'instance side' modifiers for describing a desired result, but they should always be answering an immutable instance of the class Color. self setColor: (Color red " (#FF0000) " butDarker) self color: (self color butDarker) self lightBulbColor: (Color red opacity: 0.2) As for #be vs. #as vs #newSomething, I would agree. I've beenÂ using the following conventions... Â Â Â #beX Â Â Â #beNotX (iff mode X is binary) Â Â Â #be: X Â Â Â to mean change your own state to that of mode X Â Â Â #isX Â Â Â #is: X Â Â to answer whether state is currently mode X and Â Â Â #notXÂ Â Â (iff mode X is binary) Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â rather than #isNotX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â so that the 'mode' category lists modes as Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â isY Â Â Â Â Â Â Â Â Â Â Â Â Â Â isZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notX Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notY Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â notZ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â which is easier to read when there are lots of modes. and Â Â Â #asClassX Â Â Â #as: ClassXÂ Â Â to mean answer yourself as an instance of ClassX Â Â Â #asNewClassX Â Â Â #asNew: ClassXÂ Â Â to mean answer yourself as a new instance of ClassX and Â Â Â #newSomething Â Â Â #newWith: intialValue to mean create and answer a new instance and Â Â Â #variableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public accessingÂ Â Â Â Â Â Â Â Â (possibly lazily initialed) Â Â Â #setVariableName: nilOrValue Â Â Â Â Â Â Â Â Â Â Â Â private mutating Â Â Â Â Â Â Â Â (can be reset to nil, but not otherwise changed) Â Â Â #releaseVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â private initial/release Â Â Â (if a resource) and set to nil, answer nil. Â Â Â #resetVariableOrPropertyNameÂ Â Â Â Â Â Â Â Â Â Â Â private initial/release Â Â Â reset to nil, answer self variableOrProprtyName Â Â Â #resetVariableOrPropertyName: valueÂ Â Â private initial/releaseÂ Â Â Â release (if a resource) and set to value Â Â Â #somePropertyName: valueÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â public mutatingÂ Â Â Â Â Â Â Â Â Â Â (answer self -- private mutators answer parameter) but these are all conventions for mutable objects. -Jim Jim Sawyer: jas(a)cruzio.com === --- This email has been checked for viruses by AVG. https://www.avg.com

April 29, 2019

Rename method Refactoring leads to infinite warning in latest image.

by ducasse

I could not find what was the problem. /Users/ducasse/Documents/Pharo/images/P8Evaluator/P8Evaluator.image Pharo8.0.0 Build information: Pharo-8.0.0+build.247.sha.57e3eb84cac4564882b47b87e2a977199fbe2470 (64 Bit) Unnamed May be Spec2 side effect. Good news - reproducible - can stop with cmd . https://github.com/pharo-project/pharo/issues/3275 Stef

April 29, 2019

Re: [Pharo-dev] keyboard events using Spec

by ducasse

Hello Chloe I will ask in the team to know if someone can reply to you. Now in Pharo 80 we are about to release a new spec (a first public version was released today) and esteban is working a new textPresenter so it would be really nice if you can try what he will publish because we want our users like you to be able to use it. Esteban do you have an idea when we can get a beta of the new TextPresenter @Chloe in which university are you? Are you on discord? Because you can get direct help Stef > On 29 Apr 2019, at 18:10, RaniOfTheRain <chloecampbell911(a)gmail.com> wrote: > > Hey, > > > I'm new to using Pharo and Spec and am currently trying to build a Text > Editor for a university project. > I was wondering how one would capture keyboard events in order to change the > text on a Spec LabelPresenter. > > I know there is a TextPresenter however I'm not able to use this as I need > to program my own selection code etc. > > Many thanks > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 29, 2019

keyboard events using Spec

by RaniOfTheRain

Hey, I'm new to using Pharo and Spec and am currently trying to build a Text Editor for a university project. I was wondering how one would capture keyboard events in order to change the text on a Spec LabelPresenter. I know there is a TextPresenter however I'm not able to use this as I need to program my own selection code etc. Many thanks -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 29, 2019

Re: [Pharo-dev] how implement isAbstract?

by Guillermo Polito

Hi Andrei, Doru, Sorry for the late reply, I've been away on vacations last week :). Denis introduced originally the behaviour making classes return true for #isAbstract only when they had #subclassResponsibility methods in them. Originally, if I'm not mistaken, it was to introduce the `should be implemented` protocol in Calypso: this was originally shown for subclasses of abstract classes that were not abstract themselves (under that definition). [image: image.png] My main point against that definition is that sometimes I have hierarchies like: A <|- B <|- C Where conceptually both A and B are abstract, but I only put the subclass responsibility methods in A. However under that definition B was not considered as abstract, though in my design it was. And then I had Calypso asking me all the time to <<implement>> the methods in the superclass, which I did not want to! My point at the time (and that resulted in the split of isAbstract into hasAbstractMethods) was that (at least for me) the heuristic of having abstract methods was super weak. A class is abstract by design and not necessarily because I can compute something from its implementation that tells me that maybe it is abstract. I somehow mark a class as abstract because it is abstract, not the other way around. On Tue, Apr 23, 2019 at 6:10 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I think that it is good that isAbstract does not mean isInstantiatable. > However, I also think that isAbstract is too generic and that it would be > better to have the tools implement their meaning rather than relying on a > generic term. > > Cheers, > Doru > > > On Apr 23, 2019, at 5:58 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > I ended up being surprised today that classes that have abstract > > methods (send #subclassResponsibility) were returning false to > > `isAbstract` and true to `hasAbstractMethods`. > > I see that the behavior for isAbstract changed over the years: when it > > was added [1] it was checking for abstract methods. Then it was > > changed to always return false and allow overrides [2]. > > > > Is there an explicit need to have/keep `isAbstract` at the class > > level? Users can still instantiate those classes, send message to them > > and get SubclassResponsibility errors. Tools could implement specific > > solutions for handling this. > > > > Cheers, > > Andrei > > > > [1] https://github.com/pharo-project/pharo/pull/541/files > > [2] https://github.com/pharo-project/pharo/pull/1090/files > > > > On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> On 1 Apr 2019, at 09:54, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> > >> > >> Or, if the class has subclasses, one could get a suggestion/action to > >> implement the missing method as > >> missingMethod > >> ^self subclassResponsibility > >> > >> Which also has the benefit of working nicely with the "expected (or was > that > >> "missing"?) protocol" functionality. > >> Unless you meant something else? > >> > >> > >> > >> I donât know if we are all talking about the same thing. In my image, I > have a class where I havenât got the isAbstract defined, and so Calypso > shows a red message - as it thinks Iâm supposed to implement #execute (if > it knows my intent that my class is abstract, then it doesnât show the red > warning). I think this is Denisâ question? > >> > >> Sure, if I choose to use the abstract class, then its my choice, but as > a lint checker -having useful warnings is helpful. But it is a nuisance > defining isAbstract - and Iâd almost prefer it assumes its abstract in this > case (the normal expectations?) unless I tag it as concrete and signal to > users that they might consider using my class (its probably a design smell > these days though) > >> > > > > -- > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 29, 2019

Re: [Pharo-dev] image state saving TDD

by Cyril Ferlicot

On Mon, Apr 29, 2019 at 2:55 PM Ben Coman <btc(a)openinworld.com> wrote: > > Just a thought on a dream feature... > > When doing TDD, it would be super cool if in a test method, > the state of the image was saved just before an #assert: > so if the assert fails the state is restored to just before the assert > was called, > so I don't have to <Restart> and multi-step <Over> through the whole method > to get back to the message I want to step into. > Hi, This is a feature I requested for DrTest :) https://github.com/juliendelplanque/DrTests/issues/45 > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr

April 29, 2019

image state saving TDD

by Ben Coman

Just a thought on a dream feature... When doing TDD, it would be super cool if in a test method, the state of the image was saved just before an #assert: so if the assert fails the state is restored to just before the assert was called, so I don't have to <Restart> and multi-step <Over> through the whole method to get back to the message I want to step into. cheers -ben

April 29, 2019

[ANN] Pharo Consortium New Academic Member: LIFIA

by Marcus Denker

The Pharo Consortium is very happy to announce that LIFIA has joined the Consortium as an Academic Member. About - LIFIA is a Research Center based at the Faculty of Informatics of the National University of La Plata, in Argentina. It is an associated center to the Scientific Research Commission of the Buenos Aires Province (CIC-PBA). LIFIA pioneered the use of OOP (and Smalltalk in particular) in Argentina's industry and academia. https://www.lifia.info.unlp.edu.ar/en/ - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

April 29, 2019

[Pharo 8.0] Build #247: 3214-Spec-synchronization

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

There is a new Pharo build available! The status of the build #247 was: FAILURE. The Pull Request #3216 was integrated: "3214-Spec-synchronization" Pull request url: https://github.com/pharo-project/pharo/pull/3216 Issue Url: https://github.com/pharo-project/pharo/issues/3214 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 29, 2019

[Pharo 8.0] Build #246: Fixes: #3245 to ensure that we cannot create an empty protocol.

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

There is a new Pharo build available! The status of the build #246 was: FAILURE. The Pull Request #3270 was integrated: "Fixes: #3245 to ensure that we cannot create an empty protocol." Pull request url: https://github.com/pharo-project/pharo/pull/3270 Issue Url: https://github.com/pharo-project/pharo/issues/3245 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 29, 2019

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

by Esteban Maringolo

Esteban A. Maringolo On Sun, Apr 28, 2019 at 6:02 AM ducasse <stepharo(a)netcourrier.com> wrote: > > On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> 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. > >> - '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,

April 28, 2019

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

by ducasse

> > > 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 <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 >> - '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 Nicolas Cellier

Le dim. 28 avr. 2019 Ã 08:43, ducasse <stepharo(a)netcourrier.com> 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 <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> 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 ducasse

> On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> 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 > > 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 <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 28, 2019

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

by Sven Van Caekenberghe

> 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 I agree with the above > 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 28, 2019

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

by ducasse

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 <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > Le dim. 28 avr. 2019 Ã 04:57, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> a Ã©crit : > > 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 > Hi Ben, > Why this expectation? > If i'm already a String, I rather have the right to be lazy. > The selector is not asNewString.

April 28, 2019

[Pharo 8.0] Build #245: 3238-Cleaning-ClassDefinition-package

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

There is a new Pharo build available! The status of the build #245 was: SUCCESS. The Pull Request #3267 was integrated: "3238-Cleaning-ClassDefinition-package" Pull request url: https://github.com/pharo-project/pharo/pull/3267 Issue Url: https://github.com/pharo-project/pharo/issues/3238 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 Nicolas Cellier

Le dim. 28 avr. 2019 Ã 04:57, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > 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 > Hi Ben, Why this expectation? If i'm already a String, I rather have the right to be lazy. The selector is not asNewString. >

April 28, 2019

[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