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
;)
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
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
Looks to me like HashTableSubclass is crying to get born and used…
Stef
A BlockEventHandler is x.
Instance Variables
allRecipientsBlocOrSelector:
clickBlocOrSelector:
doubleClickBlocOrSelector:
doubleClickTimeoutBlocO