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