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

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

===

---
This email has been checked for viruses by AVG.
https://www.avg.com