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@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] How to convey that a message create a new instance Message-ID: <CAJMgPCK1YB98CFn3KxhcDxLmoY7mYoXDboT5ZC2o7ZbL6pTYjA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Esteban A. Maringolo
On Sun, Apr 28, 2019 at 6:02 AM ducasse <stepharo@netcourrier.com> wrote:
On 28 Apr 2019, at 10:57, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Apr 2019, at 01:05, Gabriel Cotelli <g.cotelli@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@cruzio.com === --- This email has been checked for viruses by AVG. https://www.avg.com