On 14 November 2014 16:25, Henrik Johansen <henrik.s.johansen@veloxit.no> 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?
+1
in general, i would prefer to see: myModel propertyXYZ whenChangedDo: [...] or myModel properyXYZ whenChangedSend: #foo to: bar . - you don't have to know that it uses ValueChanged announcement. In this regard, such information is excessive, since it is standard ValueHolder. - once you learned how to access/use single property, you can use any other, because it will have same API, and so you don't have to remember numerous 'whenPropertyXYZChanged:...' hoping it is there and spelled correctly. 1. because, how i see it, the idea is , that your model exposes certain _public_ property, which application can read or change (using value/value: accessors ) or wants to be notified when it changed by others. And this can be done by simply exposing the accessor to its ValueHolder to outside. 2. the extra API is just a source of confusion. And the above example clearly illustrates why: while internally, property is named 'additionalKeyBindings', but the method for subscribing to its changes named 'whenShortcutsChanged:' . One might expect that to access such property, there should be 'shortcuts' accessor, right? No! That would be too easy. It is additionalKeyBindings! P.S. The Demeter law is not a dogma. Cheers,
Henry
-- Best regards, Igor Stasenko.