[#4766] Wiki — "Glen Stampoultzis" <trinexus@...>

21 messages 2000/09/04
[#4768] RE: Wiki — "NAKAMURA, Hiroshi" <nahi@...> 2000/09/04

Hi, Glen,

[#4783] Re: Wiki — Masatoshi SEKI <m_seki@...> 2000/09/04

[#4785] Re: Wiki — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/09/05

Howdy,

[#4883] Re-binding a block — Dave Thomas <Dave@...>

16 messages 2000/09/12

[#4930] Perl 6 rumblings -- RFC 225 (v1) Data: Superpositions — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/09/15

[#4936] Ruby Book Eng. translation editor's questions — Jon Babcock <jon@...>

20 messages 2000/09/16

[#5045] Proposal: Add constants to Math — Robert Feldt <feldt@...>

15 messages 2000/09/21

[#5077] Crazy idea? infix method calls — hal9000@...

This is a generalization of the "in" operator idea which I

17 messages 2000/09/22

[#5157] Compile Problem with 1.6.1 — Scott Billings <aerogems@...>

When I try to compile Ruby 1.6.1, I get the following error:

15 messages 2000/09/27

[ruby-talk:5141] Re: Types and ===

From: hal9000@...
Date: 2000-09-26 20:10:02 UTC
List: ruby-talk #5141
>
> class String
>         private
>         OldString = String.dup
>         public
>         def ===(other)
>                 if other.is_a? Regexp
>                         return other === self
>                 end
>                 return OldString.new(self) === other
>         end
> end
>
> --
>  Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!

Yes, this works.

This whole discussion raises some questions in my mind, though.

(By the way, I've enjoyed it. I like theoretical discussions very
much, though I have a practical side, too.)

First of all, I think I disagree with the assertion that the case
statement is usually used in non-commutative situations. I think
the most common use (this is just my first thought) is when the
tested expression is the same type as the case limb expressions,
in which case it becomes a simple equality test.

Second of all, I think it's worth noting that the meaning of
"receiver === other" doesn't just depend on the type of receiver,
but also on the type of other.

Therefore, isn't it conceivable that the === operator could be *made*
to be commutative in all circumstances? It seems to me this could be
done without violating any OOP principles.

Are there any two types X and Y such that  x===y and y===x both have
meaning, and mean different things?

Hal

--
Hal Fulton


Sent via Deja.com http://www.deja.com/
Before you buy.

In This Thread

Prev Next