[#83328] tcltklib and not init'ing tk — aakhter@... (Aamer Akhter)

Hello,

13 messages 2003/10/01

[#83391] mixing in class methods — "Mark J. Reed" <markjreed@...>

Okay, probably a dumb question, but: is there any way to define

22 messages 2003/10/01
[#83392] Re: mixing in class methods — Ryan Pavlik <rpav@...> 2003/10/01

On Thu, 2 Oct 2003 06:02:32 +0900

[#83397] Re: mixing in class methods — Gavin Sinclair <gsinclair@...> 2003/10/01

On Thursday, October 2, 2003, 7:08:00 AM, Ryan wrote:

[#83399] Re: mixing in class methods — "Mark J. Reed" <markjreed@...> 2003/10/02

On Thu, Oct 02, 2003 at 07:37:25AM +0900, Gavin Sinclair wrote:

[#83404] Re: mixing in class methods — "Gavin Sinclair" <gsinclair@...> 2003/10/02

> On Thu, Oct 02, 2003 at 07:37:25AM +0900, Gavin Sinclair wrote:

[#83416] C or C++? — "Joe Cheng" <code@...>

I'd like to start writing Ruby extensions. Does it make a difference

32 messages 2003/10/02
[#83435] Re: C or C++? — "Aleksei Guzev" <aleksei.guzev@...> 2003/10/02

[#83448] xml in Ruby — paul vudmaska <paul_vudmaska@...> 2003/10/02

The biggest problem i have with Ruby is the sleepness

[#83455] Re: xml in Ruby — Chad Fowler <chad@...> 2003/10/02

On Thu, 2 Oct 2003, paul vudmaska wrote:

[#83464] Re: xml in Ruby or no xml it's just a question — paul vudmaska <paul_vudmaska@...> 2003/10/02

>>--------

[#83470] Re: xml in Ruby — paul vudmaska <paul_vudmaska@...>

>>>

15 messages 2003/10/02

[#83551] xml + ruby — paul vudmaska <paul_vudmaska@...>

>>---------

20 messages 2003/10/03
[#83562] Re: xml + ruby — Austin Ziegler <austin@...> 2003/10/03

On Fri, 3 Oct 2003 16:11:46 +0900, paul vudmaska wrote:

[#83554] hash of hashes — Paul Argentoff <argentoff@...>

Hi all.

18 messages 2003/10/03

[#83675] fox-tool - interactive gui builder for fxruby — henon <user@...>

hi fellows,

15 messages 2003/10/05

[#83730] Re: Enumerable#inject is surprising me... — "Weirich, James" <James.Weirich@...>

> Does it surprise you?

17 messages 2003/10/06
[#83732] Re: Enumerable#inject is surprising me... — nobu.nokada@... 2003/10/07

Hi,

[#83801] Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...>

OK. So I'm going to write a text editor for my masters' thesis. The

35 messages 2003/10/08
[#83803] Re: Extension Language for a Text Editor — Ryan Pavlik <rpav@...> 2003/10/08

On Thu, 9 Oct 2003 05:06:32 +0900

[#83806] Re: Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...> 2003/10/08

* Ryan Pavlik <rpav@mephle.com> [Oct, 08 2003 22:30]:

[#83812] Re: Extension Language for a Text Editor — Ryan Pavlik <rpav@...> 2003/10/08

On Thu, 9 Oct 2003 06:09:29 +0900

[#83955] Re: Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...> 2003/10/09

* Ryan Pavlik <rpav@mephle.com> [Oct, 09 2003 09:10]:

[#84169] General Ruby Programming questions — Simon Kitching <simon@...>

21 messages 2003/10/15
[#84170] Re: General Ruby Programming questions — Florian Gross <flgr@...> 2003/10/15

Simon Kitching wrote:

[#84172] Re: General Ruby Programming questions — Simon Kitching <simon@...> 2003/10/15

Hi Florian..

[#84331] Re: Email Harvesting — Greg Vaughn <gvaughn@...>

Ryan Dlugosz said:

17 messages 2003/10/21
[#84335] Re: Email Harvesting — Hugh Sasse Staff Elec Eng <hgs@...> 2003/10/21

On Wed, 22 Oct 2003, Greg Vaughn wrote:

[#84343] Re: Email Harvesting — Ruben Vandeginste <Ruben.Vandeginste@...> 2003/10/22

On Wed, 22 Oct 2003 08:35:32 +0900, Hugh Sasse Staff Elec Eng

[#84341] Ruby-oriented Linux distro? — Hal Fulton <hal9000@...>

There's been some talk of something like this in the past.

15 messages 2003/10/22
[#84348] Re: Ruby-oriented Linux distro? — Gavin Sinclair <gsinclair@...> 2003/10/22

On Wednesday, October 22, 2003, 6:01:16 PM, Hal wrote:

[#84351] Re: Ruby-oriented Linux distro? — Andrew Walrond <andrew@...> 2003/10/22

On Wednesday 22 Oct 2003 11:02 am, Gavin Sinclair wrote:

[#84420] Struggling with variable arguments to block — "Gavin Sinclair" <gsinclair@...>

Hi -talk,

18 messages 2003/10/24
[#84428] Re: Struggling with variable arguments to block — matz@... (Yukihiro Matsumoto) 2003/10/24

Hi,

[#84604] ruby-dev summary 21637-21729 — Takaaki Tateishi <ttate@...>

Hello,

21 messages 2003/10/30
[#84787] Re: ruby-dev summary 21637-21729 — Paul Brannan <pbrannan@...> 2003/11/06

On Fri, Oct 31, 2003 at 07:01:28AM +0900, Takaaki Tateishi wrote:

[#84789] Re: ruby-dev summary 21637-21729 — matz@... (Yukihiro Matsumoto) 2003/11/06

Hi,

[#84792] Re: ruby-dev summary 21637-21729 — Paul Brannan <pbrannan@...> 2003/11/06

On Thu, Nov 06, 2003 at 11:17:59PM +0900, Yukihiro Matsumoto wrote:

[#84794] Re: ruby-dev summary 21637-21729 — matz@... (Yukihiro Matsumoto) 2003/11/06

Hi,

Re: Making == symmetric?

From: "Robert Klemme" <bob.news@...>
Date: 2003-10-01 07:40:13 UTC
List: ruby-talk #83331
"Ben Giddings" <bg-rubytalk@infofiend.com> schrieb im Newsbeitrag
news:3F7A4EBC.20007@infofiend.com...
> Nathan Weston wrote:
> > def compare(a,b)
> >    if a.can_compare_to?(b)
> >       return a.compare_to(b)
> >    elsif b.can_compare_to?(a)
> >       return b.compare_to(a)
> >    else
> >      return false
> >    end
> > end
>
> How about
>
> def compare(a, b)
>    retval = false
>    if a.can_compare_to(b)
>      retval = a.compare_to(b)
>    end
>    if retval and b.can_compare_to(a)
>      retval = b.compare_to(a)
>    end
>
>    return retval
> end
>
> This way if both of them know how to compare themselves to the other
one,
> the comparison returns true only if both agree they're equal.

But that's inefficient to a degree that can cause problems for
applications.  You end up always doing two comparisons.  Even making the
compare() method more complex (i.e do only one comparison if the
instances' classes match) doesn't really solve this issue since for the
standard case you still get the overhead.

> Aside from the code though, I'm not sure if I like the idea.  While in
> principle I agree that equality tests should be symmetrical, I also
think
> that it is more natural to have an equality operator which you can
> overload.  I think you'd still need "can_compare_to?" to know if 'a'
knows
> how to compare itself to an instance of 'b'...
>
> Maybe instead:
>
> def compare(a, b)
>    retval = false
>    if a.can_compare_to?(b)
>      retval = a.==(b)
>    end
>    if retval and b.can_compare_to?(a)
>      retval = b.==(a)
>    end
>
>    return retval
> end

Doesn't solve the overhead problem.

What one would really need is multiple dispatch:

module Kernel
  def self.register_compare(classA, classB, &comp)
    ( @comparisons ||= {})[ [classA, classB] ] = comp
    @comparisons[ [classB, classA] ] = proc { |b,a| comp.call(a, b) }
  end

  def self.compare(a, b)
    c = @comparisons[ [a.class, b.class] ]
    c.nil? ? a == b : c.call( a, b )
  end
end


class Foo
  Kernel.register_compare( self, self ) do |a,b|
    puts "Foo == Foo"
    false
  end

  def ==(b)
    Kernel.compare( self, b )
  end
end


class Bar < Foo
  Kernel.register_compare( self, self ) do |a,b|
    puts "Bar == Bar"
    false
  end

  Kernel.register_compare( self, Foo ) do |a,b|
    puts "Bar == Foo"
    false
  end
end

f1 = Foo.new
f2 = Foo.new

f1 == f2

b1 = Bar.new
b2 = Bar.new

b1 == b2

b1 == f1
f1 == b1


But this has several disadvantages, too: You keep creating all those
temporary arrays and you have the need for O(n**2) comparison operators.

Regards

    robert


In This Thread