[#796] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...>

> sean@chittenden.org wrote:

33 messages 2003/02/06
[#798] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — matz@... (Yukihiro Matsumoto) 2003/02/06

Hi,

[#826] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...> 2003/02/10

> |I have read the thread and I think this is a pretty bad change. I

[#827] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — nobu.nokada@... 2003/02/10

Hi,

[#828] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...> 2003/02/11

> > #BEGIN test.rb

[#829] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — matz@... (Yukihiro Matsumoto) 2003/02/11

Hi,

[#830] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...> 2003/02/11

> |What was wrong with having the receiver set the return value though?

[#834] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Matt Armstrong <matt@...> 2003/02/11

Sean Chittenden <sean@chittenden.org> writes:

[#835] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...> 2003/02/11

> > f = Foo.new()

[#801] class of $1, $2 in 1.8.0 — dblack@...

Hi --

31 messages 2003/02/07
[#802] Re: class of $1, $2 in 1.8.0 — nobu.nokada@... 2003/02/07

Hi,

[#803] Re: class of $1, $2 in 1.8.0 — dblack@... 2003/02/07

Hi --

[#804] Re: class of $1, $2 in 1.8.0 — matz@... (Yukihiro Matsumoto) 2003/02/07

Hi,

[#805] Re: class of $1, $2 in 1.8.0 — dblack@... 2003/02/07

Hi --

[#806] Re: class of $1, $2 in 1.8.0 — "J.Herre" <jlst@...> 2003/02/07

[#807] Re: class of $1, $2 in 1.8.0 — Matt Armstrong <matt@...> 2003/02/07

J.Herre <jlst@gettysgroup.com> writes:

[#808] Re: class of $1, $2 in 1.8.0 — dblack@... 2003/02/07

Hi --

[#809] Re: class of $1, $2 in 1.8.0 — Ryan Pavlik <rpav@...> 2003/02/07

On Sat, 8 Feb 2003 06:52:17 +0900

[#810] Re: class of $1, $2 in 1.8.0 — dblack@... 2003/02/07

Hi --

[#889] Bob Jenkins' hashing implementation in Ruby — Mauricio Fern疣dez <batsman.geo@...>

16 messages 2003/02/28
[#892] Re: Bob Jenkins' hashing implementation in Ruby — ts <decoux@...> 2003/03/01

>>>>> "M" == Mauricio Fern疣dez <Mauricio> writes:

[#893] Re: Bob Jenkins' hashing implementation in Ruby — Mauricio Fern疣dez <batsman.geo@...> 2003/03/01

On Sat, Mar 01, 2003 at 08:42:40PM +0900, ts wrote:

Re: value of assignment (Re: Order of the value of an expression changed? (PR#579))

From: Sean Chittenden <sean@...>
Date: 2003-02-06 06:58:10 UTC
List: ruby-core #796
> sean@chittenden.org wrote:
> > dblack pointed out a better test case to use:
> > 
> > # Begin
> > class Foo
> >   def a=(b)
> >     return(4)
> >   end
> > end
> > 
> > f = Foo.new
> > p f.a = 5
> > p f.a = 10000
> > # end
> > 
> > Any ideas?  The output is:
> > 
> > 5
> > 10000
> 
> It's a recent change.  See the thread from [ruby-core:644].
> 
> Now an assignment expression always return the assigned value,
> regardless its implementation.

I have read the thread and I think this is a pretty bad change.  I
can't find an instance where this would be the desired result.  When
every other expression in Ruby evaluates from right to left, why do
assignment statements always have a value of the right most value?
This breaks some of my unit tests with what I can only describe as a
"unique feature" that only Ruby has.  :-/

Here's a practical example from libxml.  libxml uses zlib for
compressing XML documents.  If you assign a value to
XML::Document#compression that is greater than 9, or less than 0, the
value used for the compression is set to either 9 or 0, respectively.

Therefore, in my unit tests I do:

assert_equal(0, doc.compression = -5)
assert_equal(9, doc.compression = 100000)

But with the way that things are now, I have to do the following:

assert_equal(-5, doc.compression = -5)
assert_equal(0, doc.compression)

assert_equal(1000, doc.compression = 1000)
assert_equal(9, doc.compression)

Which seems very counter intuitive.  If = is method (=()), then the
return value of the method should be determined by the =() method and
not by the virtue that = is an assignment operator.  Remember, from
the example above that f.a = 5 is the same as writing f.a=(5).  I
expect the f.a=() method to return whatever value f.a=() returns and
not that it will always default to the value being passed in.

Is there any chance this behavior can be reviewed further?  -sc

-- 
Sean Chittenden

In This Thread

Prev Next