[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

Re: Recent changes in Range#step behavior

From: "Rick DeNatale" <rick.denatale@...>
Date: 2008-03-30 16:30:47 UTC
List: ruby-core #16074
On Wed, Mar 26, 2008 at 5:38 PM, Dave Thomas <dave@pragprog.com> wrote:

>  By definition, ranges are defined for all objects other than a few
>  built-in ones to use succ() and comparisons. Thus they are by
>  definition a representation of a set of values.

There's been at least one rather extended thread on Ruby talk about
the requirements of range elements.
I think these two quoted sentences can be read to imply that range
endpoints MUST implement both succ() and comparisons.  I think that
this interpretation is overspecifying, and rules out useful ranges
such as

(1.5..3.0)

Such a range is quite useable as long as you restrict yourself from
using methods like each or to_a, whose implementations rely directly
or indirectly on succ.

A similar situation is that you can use

%w(one two three).sort

but not

[:one, :two, :three].sort

or at least in Ruby 1.8 where symbols aren't comparable. Of course
there are other non-sortable arrays in 1.9, for example ["one", 2,
3.0].

And I don't think we'd want to disallow, say,  heterogeneous arrays in general.

I see this as an interesting aspect of duck typing in that whether or
not a given object is a duck depends solely on exactly what quacking
it's required to do in a particular usage, and that whether or not it
can actually quack in a particular way might depend on its state and
not just its class.

> The elements in 1..3
>  are the integers 1, 2, and 3. The float 1.5 is not a member of this
>  list, so member? should return false in this case. I strongly advocate
>  fixing the current behavior so that the method name and the method
>  behavior are more aligned. That way cover? can do its thing and
>  member? can do its.

In general I agree, although one has to consider cases like this:

(1.5..3.0).member?(2.3)

I think you want to leave cases in which the end points don't quack
with the right methods (at least succ here) as undefined and let them
throw method_missing.

Exactly how much of this should be in the documentation is a question.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

In This Thread

Prev Next