From: Pixel <pixel@...>
Date: 2002-10-01T05:25:04+09:00
Subject: Re: Where Is Method Call Precedence?

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> writes:

> Mon, 30 Sep 2002 22:16:37 +0900, William Djaja Tjokroaminata <billtj@z.glue.umd.edu> pisze:
> 
> > Everything below is "obvious" and natural, isn't it?  That's why
> > I don't understand why Python does not allow mutable object to be
> > used as a hash/dictionary key in the first place.
> 
> It's not obvious that a Ruby hash doesn't put given objects as keys
> but their duplicates. In Python it puts the keys as given (strings
> and tuples are immutable so it would be a waste of time and memory
> to make duplicates).
> 
> I think the difference between Python and Ruby is more philosophical
> than technical, i.e. there mutable and immutable objects are
> technically about the same.
> 
> Technically "immutable" means that there is no operation provided which
> changes the state of the object. Philosophically it means that the
> object's identity is an artifact of the implementation and shouldn't
> be taken into account, only the value matters. It implies that passing
> them by reference and by value is the same.

on this subject, i've collected the behaviour of important types
(numbers, strings, lists, objects) in various language.

http://merd.net/pixel/language-study/various/mutability-and-sharing

as for me, the most surprising is the behaviour of strings in perl:
the deep copying is done via the "my ($s) = @_", so that you can still
have the pass by ref by accessing $_[0] directly.

i thought ruby had somehow the same behaviour, but no, the "=" doesn't
deep copy strings. Fortunately, Ruby has many purely functional
functions (eg: "s.sub(...)" vs perl's =~ s///) allowing to ignore this
problem.