Method Annotations

Avi Bryant avi at beta4.com
Wed Aug 20 23:48:16 UTC 2003


> It's not about the code, it's about the usage.
> Filing in code alone (I'm not talking about preamble/postscript do-its)
> should not do something to my system like registering menu items. What
> if I want the funtionality (generating accessors) but don't want the
> user to see it (for whatever reason)? I would then need to undo the
> effect of the annotation "manually" or maintain a branch of the code
> without annotations?

Ok, I understand what you're getting at now.  Two things:

- It's not the annotation that's adding something to a menu; it's the code
(somewhere) that's going through the system looking for particular
annotations as it builds a menu.  If you don't want it to do that, change
that code, not the annotation.  It's like saying "I want a method named
#testFoo on a TestCase subclass, but I don't want it to show up in the
TestRunner".  Well, tough - that's what the TestRunner is looking for.

- Right now, if I'm adding #generateAccessors, I do two things: I add the
method that does the work, and I *modify* the method that builds the menu.
If you don't want that menu item to show up, you still have to change the
code, only it's a lot messier because the code isn't neatly encapsulated
to begin with.

> What happens when I remove the annotation from the method? Are all
> previously registered side effects undone (if that is at all possible
> for principal reasons)?

If anything (like a menu) that's built from annotations is cached, I would
expect it to register for Roel's notifications and flush the cache at
appropiate times.  But my assumption was that usually these things would
be built on the fly anyway, so there's nothing to deregister.

> 1 : a note added by way of comment or explanation

If it's really just for explanation, put it in double quotes... if it's
more structured than that, it must be for *some* piece of code to look at,
no?



More information about the Squeak-dev mailing list