The EmptyPlugin is not a good template for new plugins authors to use, because it declares all the handlers as DISABLE_d functions. Wen I first started writing plugins I didn't realise that these functions were no-ops, and thought they had to be left in the code for the plugin to work. I suspect I am not alone in this; looking through the plugins, many plugins authors have made the same mistake I did and left these functions in-situ. As a result there is a burden of compiled-but-never-used code in many plugins.

To avoid this happening in the future I want to change the EmptyPlugin so that these functions can't get accidentally compiled. This can be achieved in (at least) three possible ways:

1. Comment them out, and add an instruction to the plugin author to uncomment those methods they need to use
2. Add an __END__ pragma in the module, and instruct the plugin author to move functions above that pragma to enable them
3. Put =pod and =cut around the functions, and add an instruction to remove them for the methods the plugin author wants to use

I checked in option 1 in r3675, before I created this topic, as I didn't think there would be any argument. My mistake.

-- CrawfordCurrie - 21 Feb 2005

(from email) The EmptyPlugin is the template for new Plugins and should be as simple to use as possible. I find that commenting out all code is unreadable and imposes also too much work to uncomment for a real Plugin. The DISABLE_function takes care of that. Yes, I know that that the code needs to be compiled. But the EmptyPlugin is disabled in an installation, so there is no need to save on the compile time. Better to keep the DISABLE_function style and add some comment on top to remove unneeded functions when creating a Plugin.

-- PeterThoeny - 21 Feb 2005

Before I revert this change and add the comment Peter is asking for, are there any other opinions?

-- CrawfordCurrie - 22 Feb 2005

I agree that commenting these functions out would be to onerous. All other suggestions are equally feasible. It depends on whether you want to make sure that the functions are not there (then go with your ideas) or whether you want to make sure that the user code will work even if the users misses this instruction.

Personally, I think the =pod and =cut idea would be simplest, as the user already needs to remove the =DISABLE_", so this is just another small, and similar, edit.

-- ThomasWeigert - 22 Feb 2005

The current approach does no harm if a Plugin author does not remove the DISABLE_* functions, except for some microseconds compile time (way less then the IO to read an additional module, so avoiding additional modules where possible is preferable but that is another subject)

The following comment was already in the header:

# initPlugin is required, all other are optional. 
# For increased performance, all handlers except initPlugin are
# disabled. To enable a handler remove the leading DISABLE_ from
# the function name. Remove disabled handlers you do not need.

If this comment is made to stick out more and if we update the TWiki.TWikiPlugins documentation accordingly we will increase the likelihood that the Plugin authors will remove the unneeded functions.

I am not in favor of the pod style commenting since it might confuse users if there is actual pod comment.

-- PeterThoeny - 23 Feb 2005

This really isn't important enough to argue further over; there are other topics that need your urgent attention far more (see DakarRelease). I'll revert the change and add an appropriate comment.

-- CrawfordCurrie - 23 Feb 2005