"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