Re: [Pharo-project] A BlockEventHandler is xxxxxxxxx.

2012-01-18 Thread Nicolas Cellier
2012/1/18 Igor Stasenko : > On 18 January 2012 08:19, Stéphane Ducasse wrote: >> Looks to me like HashTableSubclass is crying to get born and used… > > maybe. But definitely not in case of BlockEventHandler. > This class, and all of its uses should simply die. > Because it is wrong pattern to have

Re: [Pharo-project] A BlockEventHandler is xxxxxxxxx.

2012-01-18 Thread Stéphane Ducasse
;) On Jan 18, 2012, at 10:31 AM, Igor Stasenko wrote: > On 18 January 2012 08:19, Stéphane Ducasse wrote: >> Looks to me like HashTableSubclass is crying to get born and used… > > maybe. But definitely not in case of BlockEventHandler. > This class, and all of its uses should simply die. > Beca

Re: [Pharo-project] A BlockEventHandler is xxxxxxxxx.

2012-01-18 Thread Igor Stasenko
On 18 January 2012 08:19, Stéphane Ducasse wrote: > Looks to me like HashTableSubclass is crying to get born and used… maybe. But definitely not in case of BlockEventHandler. This class, and all of its uses should simply die. Because it is wrong pattern to have pluggable behavior. Every time one

[Pharo-project] A BlockEventHandler is xxxxxxxxx.

2012-01-17 Thread Stéphane Ducasse
Looks to me like HashTableSubclass is crying to get born and used… Stef A BlockEventHandler is x. Instance Variables allRecipientsBlocOrSelector: clickBlocOrSelector: doubleClickBlocOrSelector: doubleClickTimeoutBlocO