I agree, it's a good idea to delete the namespace. Problem is that some plugins can have multiple namespaces (can, although I don't think any does). So for that specific reason, I think that the plugin should do it by itself. Maybe we could write a 'amsn-plugins-lint' that checks plugin's code and tells you if you forgot to remove the namespace, or if there is any 'after' being used and not cleared, etc... would be easy to do I guess, first a tcl script that loads the plugin, then calls deinit, then checks if the namespace still exists. We could also 'grep' for all 'after' and make sure that any 'after' command has an 'after cancel' for it in the deinit, etc... and if a plugin wants to be put in our website, it must be without any warnings from the tool... ooor.. just delete the namespace ourselves and let the plugin developer test his plugin before submitting it...
either case, I think it's more a matter of choice rather than a matter of 'the good decision to make'. p.s.: Instead of the 'lint' tool, we could just update the plugin developer guide giving hints on the 'good practices' to have when developping. KaKaRoTo On Sat, Jan 05, 2008 at 04:03:33PM +0000, Tom Hennigan wrote: > I don't think we could force it, but it should be considered "good > practice" for a plugin to remove it's own namespace.. > > On 5 Jan 2008, at 16:00, Karel Demeyer wrote: > >> can't we say that cleaning those after's is a task for the plugin >> maintainer to do in the de-init procedure ? If something bugs then, it's >> the plugin's fault, not aMSN ? For me it's weird that after unloading a >> plugin it's still polluting memory ... Also this would make it really easy >> to see if a specific plugin is loaded from other plugins (namespace exist >> ::namespace). >> >> No reason for a debate ? :) >> >> Karel. >> >> 2008/1/5, Philippe Valembois - Phil <[EMAIL PROTECTED]>: >> Because if they have after scripts pending that would cause huge bugs... >> And we can't clean after scripts :s >> Phil >> >> Karel Demeyer a écrit : >> > Why are we not deleting namespaces of plugins when they are unloaded ? >> > >> > >> > Karel. >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > >> ------------------------------------------------------------------------- >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2005. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Amsn-devel mailing list >> > Amsn-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
