On 20.11.2009, at 14:41, Balázs Kósi wrote:
> 
> Hi,
>> However, I'm wary of storing blocks in the menu items.
>> 
>> The canonical style is to store a receiver and a message, which leads to far less complications down the road. That's why in the menu item we have target, selector, and arguments instance variables, instead of a block.
> Doesn't the new closure blocks mitigate those problems? Can you elaborate a bit?
> Blocks are so much more convenient.

The problem is that blocks are early-bound and opaque. You basically can't do anything with them except evaluating.

Here is what your updater block looks like in an Explorer:  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 16266 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091120/e737953c/PastedGraphic-1.png
-------------- next part --------------


I see it is a closure, and I see where it was defined, but that's about it. I can't really change it without changing the code. Okay, I could replace it with a different block in an inspector (and then even its printed representation would be meaningless).

Where it gets really hairy is when blocks get stored on file and then read back. E.g., they refer to instance variables by index. When loading them back and the class was reshaped in the mean time, they refer to the wrong instance variable. And there is hardly anything you can do about it.

Now contrast this with this menu item:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 9890 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091120/e737953c/PastedGraphic-2.png
-------------- next part --------------


It's blatantly obvious what happens, I see what it depends on, I can change it, serializing and reloading it is easy etc.

>> Also, I'd rather move the updating behavior into the submenu itself. It doesn't really make sense to reserve an inst var in every menu item, plus a top-level menu might need updating too, not just a sub menu.
>> 
>> In fact, looking at it, I'm not the first with this idea :) There is an UpdatingMenuMorph for exactly that purpose.
> It don't think that this was its exact purpose, but I hijacked it:
> Morphic-kb.242 in The Inbox.
> What do you think?

Yes, I like that better.

- Bert -