[squeak-dev] Re: Pragmas (Re: The Inbox: Morphic-phite.429.mcz)
andreas.raab at gmx.de
Mon Apr 26 23:11:32 UTC 2010
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
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
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
> 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
> 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.
More information about the Squeak-dev