Hi Henrik Thanks for your point :) I agree with you. Esteban prefered the current solution because of law of demeter but I do not think that this is good. So we will rewrite all these methods. If you want to help you are welcome. Stef On 14/11/14 16:25, Henrik Johansen wrote:
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