Interestingly, in a base 2.0 image, there isn't any user of caseOf: and very few users of caseOf:otherwise: A sample: ^ places caseOf: {[0]->[1] . [1]->[0.1] . [2]->[0.01] . [3]->[0.001] . [4]->[0.0001] . [5]->[0.00001] . [6]->[0.000001] . [7]->[0.0000001] . [8]->[0.00000001] . [9]->[0.000000001]} otherwise: [(10.0 raisedTo: places negated) asFloat] It looks like your average Pharo programmer is good at avoiding the use of caseOf: :) Thierry Le 01/08/2013 13:15, Frank Shearar a écrit :

On 1 August 2013 12:13, Frank Shearar <frank.shearar@gmail.com> wrote:

...

On 1 August 2013 12:07, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi guys

we should not use caseOf: in the image. So I will start removing them.

Other than switching on _type_, what is the problem?

foo caseOf: { [1] -> ['one']. [2] -> ['two']. } otherwise: ['three']

What's wrong with this?

I can see a reason for removing #caseOf:, precisely because it doesn't force you to consider a failed match. (#caseOf:otherwise: is always exhaustive, in other words.)

frank

...

...

Stef

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On 1 August 2013 15:20, Igor Stasenko <siguctua@gmail.com> wrote:

We had quite hot discussion about this topic in the past.. I don't think it makes sense to repeat arguments.. because i think it won't convert anyone in either camp (those who [dis]agree, will still [dis]agree). so, lets just move on.

In a way I'm not asking about the merits or otherwise of #caseOf:. I'm just wondering about what you _gain_ by removing the calls. Replacing type-switching code with polymorphism is almost always a clear win, for instance. But "kill all (non-type-switching) senders" doesn't give you much, except harder to read chained if/elses. frank

-- Best regards, Igor Stasenko.