From: Robert Klemme <bob.news@...>
Date: 2004-10-13T18:14:33+09:00
Subject: Re: Ruby Directions (was Re: quality of error messages)


"Markus" <markus@reality.com> schrieb im Newsbeitrag
news:1097599358.20674.101.camel@lapdog.reality.com...
> 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.

That's not true: Assume class Demo sits in some kind of lib.  Demo need
not be modified to be broken.  It's sufficient that Demo was written
relying on the immutability of Range.  Now after Ranges have come mutable,
 someone writes code that uses Demo in the way I presented above and
suddenly breaks Demo.  Of course you *could* distribute a new version of
the lib, but considering the latency between that and the point in time
where people do in fact update their copy there's much room for bugs.
Also, since Range is such a basic class, efforts to harden all libs that
use it against newly introduced mutability would quite high.

>  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.

Nope, You can freeze Strings, Arrays and Hashes which is a good compromize
between performance and immutability IMHO.  I regard it better suited to
Ruby as C's "const", which is quite a complex beast and makes it difficult
to get right.

>  And then we wouldn't be talking about ruby any more.

Maybe, maybe not.

Kind regards

    robert