On 14 Nov 2014, at 12:01 , stepharo <stepharo@free.fr> wrote:
I checked a bit deeper
Nautilus is not implemented in Spec. But senders and implementors are and they also leak memory. Around 400 Announcers after each opening and closing.
Now
whenChangedDo: aBlock
| block | block := [:announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann ]. announcer when: ValueChanged do: block
can also be part of the cause of some of our problems.
There are 146 senders and many of them could just be replaced by whenChanged:send:to: and whenChanged:send:to:with:
Finally we were discussing with igor about the general API of spec model: We are thinking that the following patterns are bloating the interface for an not obvious gain.
whenWindowChanged: aBlock
window whenChangedDo: aBlock
whenShortcutsChanged: aBlock <api: #event> "Set a block to value when the shortcuts block has changed"
additionalKeyBindings whenChangedDo: aBlock
I'd argue the window and additionalKeyBindings' whenChangedDo: implementations are unnecessary bloat as well. Why on earth would you limit yourself to a an API where you have to use seperate methods to register for every single announcement type? To me, myObject additionalKeyBindings when: ValueChanged do: aBlock is just as easy, if not easier to read compared to myObject whenShortCutsChanged: [] Not to mention, it easily lets you do unsubscription when you expect not to outlive the source (through the 3rd block parameter, whose *main purpose for even being there* is enabling easy unsubscription), rather than discarding it during useless indirection and leaving the task harder to do later on? Cheers, Henry