Naming of plugins

From CoreASM Wiki

As per Egon's suggestions, I propose the following naming scheme for plugins:

1. The user-visible name of a plugin should focus on the language feature added, not on the way it is implemented. Hence, I would drop the "Plugin" suffix and use instead the simple stem, e.g. "use ChooseRule".
2. Plugin resolution algorithm should be as follows:
   1. The name as provided in the "use" clause is looked up in the directory; if found, that plugin is returned;
   2. Otherwise, if the name ends in "Plugin" the lookup process fails;
   3. Otherwise, "Plugin" is added to the name and the resulting full name is looked up in the directory; if found, that plugin is returned;
   4. Otherwise, the lookup process fails.
3. Package plugins should be named after recognizable (e.g., published) sub-languages; we may want to have several "Standard" set of plugins concurrently in the future. Hence, I propose to have (at least) three package plugins:
   1. "LipariASM" should provide the Lipari Guide version of CoreASM (fixed);
   2. "TurboASM" should provide LipariASM + Turbo constructs (fixed);
   3. "CoreASM" should provide all the available plugins (variable over releases);
   4. "StandardPlugins" should provide for compatibility only the current StandardPlugins;
   5. other subsets could then be defined later on, e.g. "TASM" or even "ASML" (for a compatibility layer).
4. We may want to introduce the concept of deprecated plugins in view of future evolution:
   1. A deprecated plugin would have a special tag among its metadata (e.g., in its JAR);
   2. Loading a deprecated plugin would be permitted, but it would emit a generic warning message ("Plugin xxx has been deprecated.") followed by a custom message, also taken from the metadata, explaining the reason of the deprecation and possibly suggesting a substitute.

--Vincenzo 06:30, 6 October 2006 (PDT)