Re: TaskList API proposal

On Mon, 2002-10-28 at 09:53, Tor Norbye wrote:
> On Mon, 2002-10-28 at 06:37, Tim Lebedkov wrote:
> > Hi Tor,
> > 
> > I've read the API.
> > 1. Why don't we have SuggestionType as a class? It should be created so we
> > can simply get description or icon for type of a suggestion.
> 
> It was an attempt to reduce the number of classes in the API, and
> reduce the number of objects the user will create.
> 
> It wouldn't be sufficient to simply let the user do
> 
>     SuggestionType type = new SuggestionType("Import Problem");
>     Suggestion s = mgr.createSuggestion(type, "Import java.awt.List");
> 
> because one of the key reasons we need a type is to be able to
> store whether or not that type is enabled. Using the above, we'd
> have to either take its class name and use that as the ID, or
> force the user to declare an ID to go with it.
> 
> Having registries in the XML layer filesystem is actually done
> in a number of places in NetBeans, for example the annotations
> registry - although as you may have seen on nbdev, Jesse isn't
> all that fond of it. I'm waiting to see if Yarda has good ideas
> in this area.

I left out another big reason. The list of suggestion types has
to be generated independently of where the suggestions are created,
by the tasklist infrastructure (to create the Filter menu, for example,
or the Global Options area where you can view and disable types).
This means you'll have to go and register your SuggestionTypes
in a layer file. That means we can't have a single final SuggestionType
class; each usage would have to subclass it to provide their own
descriptions etc. That's why I said it was to reduce the number
of classes.   That also means clients have to go and add a registration
in their layer file, using the "instanceOf", "instanceCreate" etc.
attributes.  If they're already going to do that, I figured simply
dropping the class itself and providing the type attributes in the
XML directly was easier, and certainly more performant.

-- Tor