Rob van Maris <[EMAIL PROTECTED]> wrote: > I favour the idea, but I want to propose a slightly different approach: > factor the new functionality out into two different classes: > 1 - the reloadable aspect - methods reload() and reloadConfiguration() > 2 - the filewatcher triggering aspect. > > Step 1 results in a reloadable module class, but allows for additional > different triggering mechanisms, e.g. by filechanges, nodechange events > or at scheduled intervals. > Step 2 can be implemented as a subclass of the reloadable module class > (from step1), provided as a utility.
If I understand it well you want two classes: ReloadableModule extends Module and something like: AutomaticlyReloadableModule extends ReloadableModule I am not against that, and can change that without too much trouble. I do think however that this might bloat up things a bit, since both classes will probably have more license, import and doc than actual code then. And I was criticized for making to deep inheritances before :-) I'd say that if you don't want the module to be reloaded when you touch the file, then don't touch the file :-) But if nobody else objects against such a change I will do it, it will indeed conceptually be slightly nicer. Michiel -- Michiel Meeuwissen | Mediapark C101 Hilversum | +31 (0)35 6772979 | I hate computers nl_NL eo_XX en_US | mihxil' | [] () |
