[Cuis-dev] Interesting thoughts about Color

Juan Vuletich juan at jvuletich.org
Sun Apr 28 17:07:12 PDT 2019


On 4/28/2019 8:45 PM, Phil B wrote:
> Juan,
>
> On Sun, Apr 28, 2019 at 6:48 PM Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi Phil,
>
>     On 4/28/2019 2:20 PM, Phil B via Cuis-dev wrote:
>     > I was reading a thread going on over on pharo-dev about Color and
>     > thought it was apropos for us.  Many of the more commonly used
>     > instance methods (#lighter, #darker, #alpha: etc.) are named as if
>     > they were accessors or actions which would most naturally be
>     assumed
>     > to modify the current color but actually create a new color.  If
>     you
>     > work with Color to any extent the current behavior is accepted as
>     > normal since it is quasi-immutable, but this naming/behavior
>     impedance
>     > mismatch does seem pretty obvious when you think about it. 
>     Perhaps we
>     > should think about modifying these method names to better
>     reflect what
>     > they are actually doing? (and perhaps make Color more explicitly
>     > immutable?)
>
>     I think that `Color red darker` makes perfect sense. No one should
>     think
>     that it takes "red" and turns "all red" into "dark red". It should be
>     understood as 'just something like red, but darker'.
>
>
> Yes, but only if you're used to working with Color.  If you think 
> about it relative to other classes it's actually pretty weird: the 
> normal Smalltalk way of thinking would be that Color red returns a 
> (new) red color, not a singleton instance. (which I think is the crux 
> of why the implementation seems odd: it's neither a true singleton nor 
> an immediate but has a bit of feel from both)  If you had another 
> (non-Color) object instance, it would be reasonable to expect #darker 
> to make just that instance darker, not all instances or to return a 
> new instance.  So yes, you get used to it if you're used to Color... 
> but it is rather different behavior from most of the rest of the system.
>
>     #alpha: is wrong, because it really looks like a setter, but
>     Colors are
>     (at least conceptually) immutable. You can not turn red into
>     something
>     else, in the same way you can not turn 7 into something else. #alpha:
>     should be renamed #withAlpha:, so you can write `Color red withAlpha:
>     0.5` that does make sense. Same with #adjustBrightness: and
>     #adjustSaturation:brightness:.
>
>
> That was pretty much the point being made: rename the methods so it's 
> clear that they are returning a new color rather than modifying the 
> current one.  (i.e. the issue is the naming, not the underlying 
> implementation)

Maybe we could add a 'but' prefix. For example `Color red butDarker`. 
Would that sound better?

>     WRT making Color immutable... All methods that change state are
>     marked
>     as 'private'. What else do you suggest?
>
>
> Prefixing the setters with #private<whatever> would be my preference.

I see. Yes, that would be nicer. But Color already inherits #at: and 
#at:put: which we can not rename. In addition we'd need to change that 
all over the system for consistency. If my script was correct, Cuis 
includes 180 classes with a 'private' method categories.  What I'd like 
to have is real immutability.

>
> Anyway, I raised it because I thought it was an interesting and valid 
> point.  I'll leave it to you to decide what, if anything, makes sense 
> to change.
>
>     Thanks,
>
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     @JuanVuletich
>
>
> Thanks,
> Phil

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190428/bb62485c/attachment.html>


More information about the Cuis-dev mailing list