On Fri, Apr 04, 2003 at 08:25:25AM +0900, Damphyr wrote: > In the actual app I read all files in the ./lib directory with a .module > extension and use the filenames as the "plugin" names. > So each file is a way of detection (to use the semantics of my utility) > that defines a detect() method and in the app I have a method that reads > the file and builds a module out of it. > > def address(methodname) > #blabla > #construct the full pathname to the module file (fullname) > if @methods.include?(fullname) > #@methods is just an array where the contents of ./lib were read > cntnt=IO.readlines(fullname).join > IPDetector.module_eval(cntnt)#IPDetector is the app > rtrn = detect() > else > raise IPDetectorError,"Unsupported method \"#{methodname}\"!" > end > return rtrn > end > > Now, this works, but if I call address a couple of times with the > different methods I'll end up with a couple of anonymous modules. > Is there any way to clean them up? Some way to remove a mixin from a > class? I'm not sure how relevant this is to your application, but you could have a look at the way ruby-dbi handles loading of DBD drivers for different databases, which are effectively dbi "plugins". The user chooses the appropriate DBD driver with a selection string: db = DBI.connect("dbi:Mysql:test","root","") ^^^^^ That string locates the file (DBD/Mysql/Mysql.rb) which contains a module (DBI::DBD::Mysql). You don't worry about cross-pollution of the namespaces, because each module for each database driver has its own namespace. The other thing which might be useful for you is singleton classes: class Foo; end module Bar; def test; puts "hello" end end a = Foo.new # some object a.extend Bar # mixin module to this instance only a.test When you have finished with object 'a' you just forget the reference and it gets garbage collected. Then you can create a new object and mixin a different module next time. Perhaps this helps get over the need to remove a mixin. Regards, Brian.