On 20.11.2009, at 04:43, commits@source.squeak.org wrote:
Name: Morphic-kb.240 Author: kb Time: 20 November 2009, 1:40:40 am UUID: 3f82a1c6-ee8f-bf4b-98cc-a2ef45557219 Ancestors: Morphic-kb.239
- Refactoring of TheWorldMainDockingBar
- Added some helper methods to MenuItemMorph, MenuMorph, DockingBarMorph
- Added a menu to the docking bar listing windows not collapsed
Very neat! I like the menu bar :)
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.
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.
- Bert -
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.
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?
Balázs
2009/11/20 Balázs Kósi rebmekop@gmail.com:
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.
+1 the only problem with blocks, that they capturing all state (context, receiver, temps etc), required to run. And you can't replace the target as you may do it if action defined using message send..
Nonetheless, you still can mitigate these problems in blocks by using message sends , like:
onClick: [ self target buttonClicked]
instead of capturing target object directly:
onClick: [ target buttonClicked]
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?
Balázs
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:
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:
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 -
Hi, I fixed all the glitches I could find (Morphic-kb.244). I'll continue with the contents. Suggestions are welcome.
Balázs
Finally had a chance to sit down and update a trunk image. The new top menu looks fantastic!
On Sat, Nov 21, 2009 at 10:19 AM, Balázs Kósi rebmekop@gmail.com wrote:
Hi, I fixed all the glitches I could find (Morphic-kb.244). I'll continue with the contents. Suggestions are welcome.
Balázs
squeak-dev@lists.squeakfoundation.org
-
Balázs Kósi -
Bert Freudenberg -
Igor Stasenko -
Ronald Spengler