2017-10-04 11:56 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen@veloxit.no>:
Denis Kudriashov wrote
Generally it is same like having pragma with parameters. But with annotation you are not restricted by literal objects. So annotation parameters can be anything.
And it is important feature for Commander. For example I need instance of KMKeyCombination to define shortcut for command. So I just use normal expression for this:
RenamePackageCommand class>>packageBrowserShortcutActivation <classAnnotation> ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext
It will be very complicated to express it with method pragma and it will be restricted anyway.
Would it? With pure method tags, you'd do something like: SomeClass >> #renamePackage: aPackage <command: 'Rename package' category: 'Package' order: 25 shortcut: #($r meta)> ... method renaming package here ...
Then have different pragma traversers capable of creating the actual menus /
commands invoking such methods.
So instead of simple subclassing of ClassAnnotation you would suggest me to implement pragma traversal/interpreter? I would prefer first. It gives me for free the object with any structure without any tricky literal interpretation logic. For me annotation is just obviously simpler solution. Also try to think how to support blocks in parameters with pragma approach. And how fun would be to debug them. It is for the question about "restricted anyway". Really, with annotations you have normal smalltalk code for annotating classes. No magic. And implementation is really simple. (And yes, all caching/invalidation would be the responsibility of the
traverser(s) if necessary, as usual)
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html