On Thu, 2004-09-30 at 13:13, Brian Candler wrote:
> >      But "factoring out the variable" largely misses the point.  Try it
> > with a concrete example:
> >    
> > def criterion(&b)
> >     Proc.new :===,&b
> >    end

> Perhaps it makes more sense in this particular example to subclass Proc,
> giving a "Proc which has an === method for use in case statements":
> 
>   class Criterion < Proc
>     def ===(other)
>       call(other)
>     end
>   end
>   NEGATIVE = Criterion.new {|x| x < 0 }

     *smile* I'd be more enthusiastic about that if I hadn't just been
burned subclassing Proc (my whole "some Proc objects quietly exploding a
single argument if it happens to be an array bug" rant).

> Fair enough. I'd make those criteria constants, rather than local variables
> - perhaps in all-caps to avoid confusion with classes like Float.

     What's wrong with them being variables?  They are first class
citizen, after all.   We can pass them around, change their value
(imagine instead of "negative" and "prime" criteria like
"acceptable_to_most_voters" or "not_too_ugly" that may have
(complicated) values constructed elsewhere) and in general do anything
we want with the values.
     So why artificially constrain their "storage class"? 

   -- MarkusQ