2008/8/5 Lee Griffiths <poddster / gmail.com>:
> My main issue that sparked the first post was that so many things will
> just assume == gives the correct result. It does give the correct
> result, but my problem is when they're imbedded deep inside two objects
> that are compared to each other using ==, and these objects just naivey
> ask all their internal attributes if they == other.attribute . So why
> doesn't Ruby have, by default:
>
> a) a built in =~ or Float#approx(other) method?
> b) The ability to "switch on" and "off" wether == or =~ is used whenever
> == is called (I hope that makes sense!)?
>
> Whilst for now my extensions to Float will do (for me, at least), I
> think that the default Ruby float class should deal with this issue
> without having to drag up BigDecimal. What do you all think? Is built in
> fuzzy checking, and the option to use it on or off to much to ask?

I believe the problem with this is its high potential for catastrophe:
assume you have a bit of code that uses a library which in turn uses
another lib.  You switch fuzzy on but it is not selective, i.e. will
affect all comparisons - in both libs, one of them you might not even
be aware of using.  Code written with the assumption that the flag is
switched off will go awry.

After all, there is a standard and I believe it is a bad idea to allow
standard classes to deviate from that.  And embedding the flag switch
in code that requires standard behavior will clutter it quite a lot.

IMHO the proper solution would be to craft your own float math class
that just wraps a Float and implements == the way you like while
otherwise behaving as float.  I would not mess with Float#== not even
temporarily.

Kind regards

robert


-- 
use.inject do |as, often| as.you_can - without end