"Martin DeMello" <martindemello / yahoo.com> schrieb im Newsbeitrag news:Zas7b.80408$_5.1349095 / news1.telusplanet.net... > Robert Klemme <bob.news / gmx.net> wrote: > > > No, this seems overly complex to me and (more important) these tests have > > nothing to do with Sets per se. You should then create a sub class of Set > > that contains all match methods. But the other approach (individual > > classes per test) is more modular, flexible and easier to extend. If you > > hava a single Set sub class that contains all tests you'd have to use > > something like this for all matches > > > > def all_matches? > > public_methods.grep( /^match/ ).each do |m| > > return false unless self.send m > > end > > true > > end > > This seems rather heavy and, well, Java-like (where you're forced to > create a class because you can't have unattached procs). Hm, I find this clearer - just because certain things can be done does necessarily mean that's the best way to do it. > A test is, > conceptually, an unbound function, and Ruby does indeed give us a > mechanism to create such. I assume you mean blocks / procs. The OP stated that the tests are fairly complex, that's why IMHO a class per test type seems more appropriate since then handling of state (i.e. instance vars) is handled more gracefully than in a block. Of course it can be done there, too, but the complexity calls for separate classes. The other solution that I find appropriate is to create a module that is used for extending specific set instances (those that carry the data which I want to apply the tests to). My 2 cent... Regards robert