On 4/26/2010 3:47 PM, Hannes Hirzel wrote:
> And: to me the code for the menu definitions looks ugly. A kind of
> assembler like, lisp-s expression thing with a lot of implied
> assumptions.

I think you're missing the point of why one would use an annotation. 
They're there for discovery by other code. You are basically announcing 
"hey if anyone cares, here's an action that you might want to place in a 
menu".

MenuSpec doesn't achieve that. Yes, you got a menu spec, but now what? 
You also need a registry, let's say TheWorldMenu. Then you add another 
registry for TheMainDockingBar. Then we refactor this and introduce new 
classes, say the TheMainMenu and TheContextMenu. Now you've got to deal 
with four different situations. This all goes away by using annotations. 
If there's code that knows how to discover these specs, it will do so. 
If not, it just leaves the code alone.

Most importantly a third party trying to extend the main menu doesn't 
need to update their code because the implementation in the base system 
changes.

> The MenuSpec is a straighforward thing. And I think it is more
> appealing for the younger generation.

I fail to see what age has to do with this discussion. However, if you 
look at the "current" crowd of programming languages they pretty much 
all have annotations, from C# to Python, which are used for very similar 
purposes.

> The practical problem we are currently facing with Squeak 4.1 is that
> it cannot display pictures in the the file browser and that adding
> entries to the menu is not possible in a clean way.

Correct, but I see this as a an example of a discussion on how we 
achieve a more decoupled system. For the purpose at hand, where we'd 
like 3rd parties to use and extend the base system while allowing the 
base system itself to evolve, I find the annotation-based discovery 
superior to hardcoded references to classes and registries that may not 
exist in this form in the future.

Cheers,
   - Andreas