[#17198] enhancing Ruby error messages for out of the bound constant Fixnum? — Guillaume Cottenceau <gc@...>

Hi,

11 messages 2001/07/03

[#17206] /* */ comments — Dave Thomas <Dave@...>

43 messages 2001/07/04
[#17207] Re: /* */ comments — Stephen White <spwhite@...> 2001/07/04

On Wed, 4 Jul 2001, Dave Thomas wrote:

[#17251] Re: /* */ comments — Sean Chittenden <sean-ruby-talk@...> 2001/07/04

> Over on http://www.rubygarden.org, dv posted a patch to parse.y that

[#17268] Re: /* */ comments — matz@... (Yukihiro Matsumoto) 2001/07/05

Hi,

[#17212] Ruby 1.6.4 Win32 .exe installer question — A Bull in the China Shop of Life <feoh@...>

Folks;

11 messages 2001/07/04

[#17225] Re: /* */ comments — Arnaud Meuret <ameuret@...4you.com>

|From: Mark Slagell [mailto:ms@iastate.edu]

17 messages 2001/07/04

[#17240] Ruby Mascot/logo — "Kevin Powick" <kpowick@...>

Hi there.

14 messages 2001/07/04

[#17281] Inheritance — "Aleksei Guzev" <aleksei.guzev@...>

15 messages 2001/07/05
[#17282] Re: Inheritance — ts <decoux@...> 2001/07/05

>>>>> "A" == Aleksei Guzev <aleksei.guzev@bigfoot.com> writes:

[#17348] Adding a method to a class at the top-level — Guillaume Cottenceau <gc@...>

Comrades,

14 messages 2001/07/05

[#17482] Aliases for class methods — "HarryO" <harryo@...>

Say I wanted to write my own version of File#open that adds some

23 messages 2001/07/08

[#17511] Ruby on Slashdot — jweirich@...

Ruby is currently mentioned on Slashdot. I posted some references.

29 messages 2001/07/08
[#17512] Re: Ruby on Slashdot — Tobias Reif <tobiasreif@...> 2001/07/08

Interesting...

[#17518] Re: Ruby on Slashdot — matz@... (Yukihiro Matsumoto) 2001/07/09

Hi,

[#17519] Re: Ruby on Slashdot — "James (ruby-talk)" <ruby@...> 2001/07/09

> |I thought about that too; what about Ruby being a standard?

[#17525] Re: Ruby on Slashdot — matz@... (Yukihiro Matsumoto) 2001/07/09

Hi,

[#17536] Re: Ruby on Slashdot — David Alan Black <dblack@...> 2001/07/09

Hello --

[#17572] Re: Constants and Variables — "HarryO" <harryo@...>

> If you want objects that don't change, try Object#freeze,

25 messages 2001/07/10

[#17732] Re: Array#sort! returns nil when array empty — hfulton@...

> Array#sort! returns nil if the array is empty, whereas ri

32 messages 2001/07/12
[#17736] Re: Array#sort! returns nil when array empty — Paul Brannan <pbrannan@...> 2001/07/12

On Fri, 13 Jul 2001 hfulton@pop-server.austin.rr.com wrote:

[#17739] Re: Array#sort! returns nil when array empty — ts <decoux@...> 2001/07/12

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#17746] Re: Array#sort! returns nil when array empty — Paul Brannan <pbrannan@...> 2001/07/12

On Fri, 13 Jul 2001, ts wrote:

[#17747] What is Array#- ? — Jim Freeze <jim@...> 2001/07/12

While following the Array thread, I noticed the minus

[#17752] Re: What is Array#- ? — Dave Thomas <Dave@...> 2001/07/12

Jim Freeze <jim@freeze.org> writes:

[#17753] Re: What is Array#- ? — Jim Freeze <jim@...> 2001/07/12

On Fri, 13 Jul 2001, Dave Thomas wrote:

[#17833] Extending objects — "Aleksei Guzev" <aleksei.guzev@...>

16 messages 2001/07/14
[#17834] Ruby-newbie seeks help with Rubywin starting IRB — "Euan Mee" <lucid@...> 2001/07/14

Once I fire up Rubywin, and then invoke _R_uby _I_rb from the

[#17839] Re: Ruby-newbie seeks help with Rubywin starting IRB — A Bull in the China Shop of Life <feoh@...> 2001/07/14

At 07:05 PM 7/14/01 +0900, Euan Mee spewed forth:

[#17859] Re: Creating methods on the fly — "HarryO" <harryo@...>

I

18 messages 2001/07/15

[#17925] Movement in scripting language communities to integrate XML-RPC — gsemones@... (Guerry Semones)

Greetings,

20 messages 2001/07/16
[#17934] Re: Movement in scripting language communities to integrate XML-RPC — Tobias Reif <tobiasreif@...> 2001/07/16

"out of the box" by including

[#18018] Broadcasting data — "HarryO" <harryo@...>

Does someone have an example of broadcasting data around a network using

12 messages 2001/07/18

[#18023] [ANN] libxslt Rubified! — Wai-Sun Chia <waisun.chia@...>

Hello,

16 messages 2001/07/18
[#18024] Re: [ANN] libxslt Rubified! — TAKAHASHI Masayoshi <maki@...> 2001/07/18

Wai-Sun Chia <waisun.chia@compaq.com> wrote:

[#18100] Looking for Ruby programming exercises — Wayne Vucenic <wvucenic@...> 2001/07/19

I've been learning Ruby, mostly with the Pickaxe book, and it's going

[#18188] Newbie. Sinking fast. Please help. — Matt <matt@...>

I bought Programming Ruby a number of months back and finally have an opportunity to try out Ruby. However, I can't get it to build. Actually, that's not quite accurate. It builds fine. It won't pass 'make test'.

12 messages 2001/07/20

[#18193] Re: 99 bottles of beer — "Dat Nguyen" <thucdat@...>

18 messages 2001/07/20
[#18204] Re: 99 bottles of beer — Glen Starchman <glen@...> 2001/07/20

99.downto(0){|x|w=" on the wall";u="#{x!=0?eval(x.to_s):'no more'}

[#18306] Ruby as opposed to Python? — "Mark Nenadov" <mnenadov@...>

Hello. I have toyed with the idea of trying Ruby out for some time now.

118 messages 2001/07/22
[#18759] Re: Ruby as opposed to Python? — Paul Prescod <paulp@...> 2001/07/29

Yukihiro Matsumoto wrote:

[#18774] Re: Ruby as opposed to Python? — "Florian G. Pflug" <fgp@...> 2001/07/30

On Mon, Jul 30, 2001 at 05:58:22AM +0900, Paul Prescod wrote:

[#18393] Trouble Using FXRuby on cygwin/Windows NT — rgilbert1@... (Robbie Gilbert)

Hi,

10 messages 2001/07/23

[#18566] Which database should I use? — Urban Hafner <the-master-of-bass@...>

Hello everybody,

17 messages 2001/07/26
[#18575] Re: Which database should I use? — Urban Hafner <the-master-of-bass@...> 2001/07/26

[#18582] Re: Which database should I use? — Michael Neumann <neumann@...> 2001/07/26

Urban Hafner wrote:

[ruby-talk:18401] Re: interfaces?

From: jweirich@...
Date: 2001-07-24 02:45:22 UTC
List: ruby-talk #18401
>>>>> "MikkelFJ" == MikkelFJ  <mikkelj-anti-spam@post1.dknet.dk> writes:

    MikkelFJ> Are there interfaces in Ruby? If not, why not?

    MikkelFJ> However, I would like to be able to query an object
    MikkelFJ> about an interface, such that I know I can trust it to
    MikkelFJ> do the expected.

    MikkelFJ> shape_collection.each do  |obj|
    MikkelFJ>   case obj
    MikkelFJ>   when IRayIntersection
    MikkelFJ>     clip_using_interface(obj)
    MikkelFJ>   when Box
    MikkelFJ>     clip_as_rectangle(obj)
    MikkelFJ>   when Sphere
    MikkelFJ>     clip_as_circle(obj)
    MikkelFJ>   end
    MikkelFJ> end

Assuming the choice of clipping algorithm rests solely in the type of
Shape, then moving the clipping algorithm into the shape objects make
a lot of sense.  Then your code will look like ...

    shape_collection.each { |shape| shape.clip }

If a BoxWithHole can't use the standard box algorithm, it will
implement the IRayIntersection algorithm for its version of clip.  No
need to search a list of possible algorithms.  Best of all, if you add
a new algorithm there is no need to update this case statement (and
any others you might have).

On the other hand, it is possible that the choice of clipping
algorithm is dependent upon both the sender and receiver.  In other
words, clipping a box against a box is different than clipping a
circle against a box, which in turn is different from circle/circle
clipping.  This is a tougher problem.

One possibility is using a double dispatch setup like this (sorry
about the long example) ...

# START CODE ---------------------------------------------------------
module ClippingAlgorithms
  def box_circle_clip(box, circle)
    puts "Box/Circle Clipping"
  end
  def circle_circle_clip(circle1, circle2)
    puts "Circle/Circle Clipping"
  end
  def box_box_clip(box1, box2)
    puts "Box/Box Clipping"
  end
end
			    
class Circle
  include ClippingAlgorithms
  def clip(other)
    other.circle_clip(self)
  end
  def circle_clip(circle)
    circle_circle_clip(self, circle)
  end
  def box_clip(box)
    box_circle_clip(box, self)
  end
end

class Box
  include ClippingAlgorithms
  def clip(other)
     other.box_clip(self)
  end
  def circle_clip(circle)
    box_circle_clip(self, circle)
  end
  def box_clip(box)
    box_box_clip(self, box)
  end
end

b = Box.new
c = Circle.new

b.clip(b)  #=> Box/Box Clipping
c.clip(c)  #=> Circle/Circle Clipping
b.clip(c)  #=> Box/Circle Clipping
c.clip(b)  #=> Box/Circle Clipping
# END CODE -----------------------------------------------------------

The downside is that adding new shapes causes an explosion of new
combinations.  Sometimes this can be mitigated through judicious use
of inheritance.

If you don't need the complexity, obviously the first solution is much
better.

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

In This Thread