oh, well... but it's also doable this way: 

guessTypeOf: aNumber 
        | range |
        self configureSelectorsOnly.
        recurseCount > 10 ifTrue: [ ^ nil ].
        recurseCount := recurseCount + 1.
        range := ranges at: aNumber.
        
        range isSelf ifTrue: [ ^theClass ].
        range isSuper ifTrue: [ ^theClass superclass ].
        range isConstant ifTrue: [ ^range asType ].
        range isArgument ifTrue: [ ^self guessArgument: range ].
        range isTemporaryVariable ifTrue: [ ^self guessTempVarClass: range ].
        range isInstanceVariable ifTrue: [ ^self guessInstVarClass: range ].
        range isClassVariable ifTrue: [ ^self guessClassVarClass: range ].
        range isGlobal ifTrue: [ ^self guessGlobal: aNumber ].


which of course has it's drawbacks (like multiple returns, which I also was 
told it is usually a bad thing), but I think is much clearer... and the usual 
way to do case statements on smalltalk.
btw... this implementation reveals a bug: there is no default behavior if none 
of the conditions is fulfilled. In that case, it will answer "self", and I 
think that's wrong (I think it should answer nil). Not sure, because never dug 
into this code before, but looks like :)


On Apr 23, 2012, at 12:49 PM, Nicolas Cellier wrote:

> These are not really nested if, but rather a kind of caseOf:
> implemented with elseif.
> It's not to say that the style is ideal...
> I did not read the code, and don't know what a range is, nor if it has
> subclass specializations.
> If so, maybe some actions could simply be dispatched to range.
> 
> Nicolas
> 
> Le 23 avril 2012 10:58, Esteban Lorenzano <[email protected]> a écrit :
>> he... is not related with the error, but... did you see this method?
>> 
>> guessTypeOf: aNumber
>>        | range |
>>        self configureSelectorsOnly.
>>        recurseCount > 10 ifTrue: [ ^ nil ].
>>        recurseCount := recurseCount + 1.
>>        range := ranges at: aNumber.
>>        ^ range isSelf
>>                ifTrue: [ theClass ]
>>                ifFalse:
>>                        [ range isSuper
>>                                ifTrue: [ theClass superclass ]
>>                                ifFalse:
>>                                        [ range isConstant
>>                                                ifTrue: [ range asType ]
>>                                                ifFalse:
>>                                                        [ range isArgument
>>                                                                ifTrue: [ 
>> self guessArgument: range ]
>>                                                                ifFalse:
>>                                                                        [ 
>> range isTemporaryVariable
>>                                                                              
>>   ifTrue: [ self guessTempVarClass: range ]
>>                                                                              
>>   ifFalse:
>>                                                                              
>>           [ range isInstanceVariable
>>                                                                              
>>                   ifTrue: [ self guessInstVarClass: range ]
>>                                                                              
>>                   ifFalse:
>>                                                                              
>>                           [ range isClassVariable
>>                                                                              
>>                                   ifTrue: [ self guessClassVarClass: range ]
>>                                                                              
>>                                   ifFalse: [ range isGlobal ifTrue: [ self 
>> guessGlobal: aNumber ] ] ] ] ] ] ] ]
>> 
>> 
>> when I was younger, at informatics school, they told me that "3 nested ifs 
>> means bad design, with no doubt"... what about 7?
>> 
>> 
>> On Apr 23, 2012, at 10:30 AM, Esteban Lorenzano wrote:
>> 
>>> yes, I can reproduce this one... taking care of it now :)
>>> 
>>> On Apr 23, 2012, at 10:11 AM, Stéphane Ducasse wrote:
>>> 
>>>> Note that the bug shows up if you edit the code in the result of the 
>>>> implementors.
>>>> Esteban can you reproduce the bug?
>>>> 
>>>> Stef
>>>> 
>>>> On Apr 23, 2012, at 9:18 AM, Stéphane Ducasse wrote:
>>>> 
>>>>> Hi
>>>>> 
>>>>> I get a bug with OCompletion/Ecompletion
>>>>> 
>>>>> TextEditor>>changeEmphasis
>>>>> 
>>>>> try to type
>>>>> 
>>>>>     menuList nextPut:
>>>>> 
>>>>> and you get a bug.
>>>>> 
>>>>> Now in addition I do not understand what I see in the debugger:
>>>>> 
>>>>> As you see model returns a debugger and the debugger title show 
>>>>> FlatMessageListBrowser
>>>>> 
>>>>> Stef
>>>>> 
>>>>> 
>>>>> 
>>>>> <Screen Shot 2012-04-23 at 9.08.45 AM.pdf>
>>>> 
>>>> 
>>> 
>> 
>> 


Reply via email to