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.