On Tue, 2004-10-12 at 08:34, Robert Klemme wrote:
> "Markus" <markus / reality.com> schrieb im Newsbeitrag
> news:1097593941.20674.27.camel / lapdog.reality.com...
> > On Tue, 2004-10-12 at 00:09, Robert Klemme wrote:
> > > Regardless of whether Ranges should rather be immutable or not, I
> plead
> > > for sticking with the current immutability.  The reason is simply that
> a
> > > change of mutability of a class is a major change, which is likely to
> > > break a lot of code.  Everybody that relied on a Range being immutable
> and
> > > thus stored an instance as member of his own classes might recognize
> the
> > > range suddenly changed when it's no longer immutable.
> >
> >      I'm not sure I understand your point; could you provide an example
> > of how this might happen?  Specifically, how code that did not attempt
> > to modify something would be affected if it became, in theory, possible
> > to modify it.  Or am I misunderstanding?
> 
> class Demo < Struct.new(:range)
>   def show
>     range.each {|val| puts val}
>   end
> end
> 
> r = 1..10
> d = Demo.new r
> d.show
> # modify r in place
> d.show
> 
> In this scenario the second "d.show" will unexpectedly print something
> else if r could be modified in place.

     But the point is, if the code _does_not_ attempt to modify the
range now, it won't magically realize if ranges became mutable and
suddenly  start modifying them.

    Yes, if ranges were to become mutable (and note, I am NOT arguing
that they should) it would permit a new class of bugs to be written. 
But it wouldn't break existing, functional code.  You may be correct,
that the example you gave was a serious problem, but then I would expect
you to argue that strings should be immutable too.  And arrays.  And
hashes.  And then we wouldn't be talking about ruby any more.

-- Markus