From: David Vallner <david@...>
Date: 2006-02-22T09:10:35+09:00
Subject: Re: dirty ranges

Dňa Utorok 21 Február 2006 13:23 Dirk van Deun napísal:
> For the people who remarked (quite sensibly, of course) that you just
> shouldn't do that, tinker with the endpoints of a range: it works
> the other way too, of course:
>
> irb(main):001:0> rng="a".."z"
> => "a".."z"
> irb(main):002:0> arr=rng.to_a
> => ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
> "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z"]
> irb(main):003:0> arr[0][0]="z"
> => "z"
> irb(main):004:0> rng
> => "z".."z"
>

Commandment <number> of not causing obscure bugs: thou shalt not clobber 
shared data without due reason. 

I can't imagine why I'd model any functionality with in-place modification of 
something two levels deep in a data structure I have as input. The whole 
approach is bound to cause problems sooner or later if you really don't know 
what you're doing, in this specific case it's just a bit more visible because 
it's obvious that Range object makes little sense.

> The begin/end versus min/max I obviously didn't know, but then again,
> if max is an ad-hoc constructed object, shouldn't min be too, if
> only for symmetry ?
>

How'd you do it? The only requirement Range places on its beginning point is 
comparability and generating successors (if enumerating the members). 

No cloneability mentioned anywhere, even if it would happen to help in case of 
Strings. For example, the problem can't appear with Fixnums, and you can't 
dup those or clone those - IIRC o.object_id != o.dup.object_id must hold true 
for the operation to be correct, same for clone.

A lose / lose situation basically, but I prefer the currently used option that 
puts things in my hands. 

David Vallner