The Inbox: Graphics-ct.410.mcz

Am 15.08.2019 02:16:53 schrieb Tobias Pape <[hidden email]>:

> On 14.08.2019, at 23:52, [hidden email] wrote:
>
> A new version of Graphics was added to project The Inbox:
> http://source.squeak.org/inbox/Graphics-ct.410.mcz
>
> ==================== Summary ====================
>
> Name: Graphics-ct.410
> Author: ct
> Time: 14 August 2019, 11:52:24.4754 pm
> UUID: 008f8bb1-9963-1e46-8b29-1f1e2aa3235b
> Ancestors: Graphics-nice.409
>
> Little refactoring to HSV conversion
>
> Afaik #caseOf: is compiler optimized, so this is not only more beautiful but also at least at efficient as the old conditional chain, isn't it?
>

-1.

I do not hold that caseOf is more beautiful. It may be a matter of taste, here.
But often it's an instance of forgotten polymorphy, so I'm against promoting it outside "important" uses, eg in Parser or so.

I see that this is a lot number-dancing and maybe not even an important method, so it might not matter much.
Yet I don't see benefit in the #caseOf variant.

Best regards
-Tobias

> =============== Diff against Graphics-nice.409 ===============
>
> Item was changed:
> ----- Method: Color>>setHue:saturation:brightness: (in category 'private') -----
> setHue: hue saturation: saturation brightness: brightness
> "Initialize this color to the given hue, saturation, and brightness. See the comment in the instance creation method for details."
>
> | s v hf i f p q t |
> s := (saturation asFloat max: 0.0) min: 1.0.
> v := (brightness asFloat max: 0.0) min: 1.0.
>
> "zero saturation yields gray with the given brightness"
> s = 0.0 ifTrue: [ ^ self setRed: v green: v blue: v ].
>
> hf := hue asFloat.
> (hf < 0.0="" or:="" [hf="">= 360.0])
> ifTrue: [hf := hf \\ 360].
> hf := hf / 60.0.
> i := hf asInteger. "integer part of hue"
> f := hf fractionPart. "fractional part of hue"
> p := (1.0 - s) * v.
> q := (1.0 - (s * f)) * v.
> t := (1.0 - (s * (1.0 - f))) * v.
>
> + ^ i caseOf: {
> + [0] -> [ self setRed: v green: t blue: p ].
> + [1] -> [ self setRed: q green: v blue: p ].
> + [2] -> [ self setRed: p green: v blue: t ].
> + [3] -> [ self setRed: p green: q blue: v ].
> + [4] -> [ self setRed: t green: p blue: v ].
> + [5] -> [ self setRed: v green: p blue: q ]. }!
> - 0 = i ifTrue: [ ^ self setRed: v green: t blue: p ].
> - 1 = i ifTrue: [ ^ self setRed: q green: v blue: p ].
> - 2 = i ifTrue: [ ^ self setRed: p green: v blue: t ].
> - 3 = i ifTrue: [ ^ self setRed: p green: q blue: v ].
> - 4 = i ifTrue: [ ^ self setRed: t green: p blue: v ].
> - 5 = i ifTrue: [ ^ self setRed: v green: p blue: q ].
> -
> - self error: 'implementation error'.
> - !
>
>

What should be the general problem with #caseOf:? Just in this example, I think #caseOf: provides a better alternative to an amount of logic. #caseOf: describes a more data-driven approach to express repeating logic. In particular when you don't have a default case, you won't need to explicitly write a check for that, but #caseOf: will handle that for you (so I think in the current example, a caseError just has the right semantic. Apart from that I think errors that are never ever expected to be raised are some kind of code smell).

Of course, excessive use of #caseOf: might indicate the lack of an inheritance tree, but I don't think this is specific to #caseOf:, the same smell can be written with many conditionals as well.

Best,

Christoph

Am 15.08.2019 18:59:06 schrieb tim Rowledge <[hidden email]>:

> On 2019-08-15, at 2:10 AM, Thiede, Christoph wrote:
>
> Of course, excessive use of #caseOf: might indicate the lack of an inheritance tree, but I don't think this is specific to #caseOf:, the same smell can be written with many conditionals as well.

It is a long understood truism that there is no language in which the poor programmer cannot write FORTRAN.

I've long ago lost count of the number of times I have seen stuff like

(thing isKindOf: Weeble) ifTrue:["do something daft"].
(thing isKindOf: Blobby) ifFalse: ["do related ridiculous thing that could be factored properly"].
thing doodah caseOf: .... etc etc

I used to find it disheartening. Now I just find it tedious and occasionally profitable as I get paid to make it right.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Government organization