matz / ruby-lang.org (Yukihiro Matsumoto) wrote in message news:<1006609296.177024.18115.nullmailer / ev.netlab.jp>...
> Hi,
> 
> In message "[ruby-talk:26298] Re: String#== : Why not error with different type?"
>     on 01/11/24, Ryo Furue <furufuru / ccsr.u-tokyo.ac.jp> writes:
> 
> |Then, the problem is: What is the most "natural" (intuitive)
> |definition of '==' ?  I'd like to argue that most programmers think
> |(or "feel") they are comparing "values" in their mindset when they say
> |'=='; they don't (usually) think they are comparing values *and*
> |types.
> 
> Ah, this is the point.  In dynamic way of thinking, objects are
> values.  You don't have to separate type and values.  You don't have
> to think about types.

I got it!  Thanks for the explanation.  It seems that I've spent too
much time with statically-typed languages and I've been "spoiled" by
the sense of security that statically-taped-ness brings.  But, I
wonder:  Don't you (not only you, Matz, but also you Ruby programmers
in general) a little bit fear this flexibility?  I said "sense of
security" because type mismatch very often indicates mistakes. (See
the exmaple of a bug I gave in my original post).  Indeed, the C++
compiler often keeps me from making trivial mistakes by pointing out
type mismatch.  It did help me a lot when I was using C++.  How do you
protect yourself from such mistakes as I made in Ruby?  I've decided
that I will normally say

	if (a <=> b) == 0 # a and b should be Strings.

when polymorphism (of a) isn't intended or expected.  And I would
expect that more than 95% of my String comparisons involve (and
*should* involve) only Strings.  How often in practice do you need to
compare a non-String with a String?  I know this way of thinking isn't
a "dynamic way of thinking", perhaps :-)

> Introducing type checks too much may reduce flexibility of dynamic
> typed languages.  Dave Thomas would talk you about "duck typing",
> maybe.

Please do, Dave.  I'm curious.

Cheers,
Ryo