2011/8/8 Igor Stasenko <[email protected]>:
> 2011/8/8 Nicolas Cellier <[email protected]>:
>> I also noted this: (Array does notUnderstand: #nextPut:) and it comes from:
>>
>> MouseOverHandler>>handleAsMouseEnter: anEvent
>> | asMouseEnterEvent |
>> asMouseEnterEvent := anEvent asMouseEnter.
>> enteredMorphs := enteredMorphs contents.
>> enteredMorphs reverseDo: [ :anEnteredMorph |
>> self inform: asMouseEnterEvent to: anEnteredMorph
>> originatedFrom:
>> anEvent ifNotFocusedDo: [] ]
>>
>> enteredMorphs is changing indead from WriteStream -> Array.
>> IMHO mutating an inst var is very bad behaved
>> This should be corrected ASAP
>>
>
> This class is really confusing..
> According to its use (see senders to #mouseOverHandler)
> it actually handling more than just mouse over events.
> I would say it should be named MouseEventHander :)
>
> But still , its hard to say, why it is so complex.. and what its purpose.
>
Yeah, Squeak version of this class was worse, even the comments are
cryptic like :
enteredMorphs ifNil: [ "inform: was called in handleEvent:"
^self initializeTrackedMorphs ].
Squeak already broke the enteredMorph ivar, but reset it at the end of
the method with a
self initializeTrackedMorphs
OK, some clean up was required, but you see, you can make things worse
when cleaning...
It's like Pharo cleaning removed the antidote, but forgot to remove
the poison...
Now, of course, instead of a local polishing, it would be possible to
rewrite all.
But please, don't do it blindly and loose 2 third of features like the
new implementors window :(
Nicolas
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
