In case anyone's really been missing chained assignment

Does this mean that we will get to decide whether our equality chains or not?

I thought the original justification for not chaining was performance: returning the original object cost more than not returning anything (i.e. returning ()).  Has that changed?

I do like chained assignment, but if there is actually a performance penalty, I'm not sure I want to pay it; and if the user gets to choose whether there's chained assignment or not, wouldn't that get confusing?  If the user does not get to choose, what about legacy code?

  --Rex

On Fri, Dec 23, 2011 at 2:07 PM, Paul Phillips <paulp@improving.org> wrote:

scala> class A[T](init: T) { private var _x = init ; def x = _x ; def x_=(y: T): T = { _x = y ; y } }defined class A
scala> new A("abc")res0: A[String] = A@7d740df7
scala> new A("def")res1: A[String] = A@2628de85
scala> res0.x = res1.x = "BIPPY"res0.x: String = BIPPY
scala> res0.xres2: String = BIPPY
scala> res1.xres3: String = BIPPY

On Fri, Dec 23, 2011 at 12:56 PM, Rex Kerr <ichoran@gmail.com> wrote:

Does this mean that we will get to decide whether our equality chains or not?

I thought the original justification for not chaining was performance: returning the original object cost more than not returning anything (i.e. returning ()).  Has that changed?

I do like chained assignment, but if there is actually a performance penalty, I'm not sure I want to pay it; and if the user gets to choose whether there's chained assignment or not, wouldn't that get confusing?  If the user does not get to choose, what about legacy code?

I think you misunderstand me.  That's not some hypothetical feature.  That's what you've always been able to do.

# Let's get in the wayback machine, mr. peabody!% scala27Welcome to Scala version 2.7.7.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_29).Type in expressions to have them evaluated. Type :help for more information.
scala> class A[T](init: T) { private var _x = init ; def x = _x ; def x_=(y: T): T = { _x = y ; y } }defined class A
scala> new A("abc")  res0: A[java.lang.String] = A@442b7fc2
scala> new A("def")res1: A[java.lang.String] = A@6b38dba
scala> res0.x = res1.x = "BIPPY"
scala> res0.xres2: java.lang.String = BIPPY
scala> res1.xres3: java.lang.String = BIPPY

On Fri, Dec 23, 2011 at 4:30 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Dec 23, 2011 at 12:56 PM, Rex Kerr <ichoran@gmail.com> wrote:

Does this mean that we will get to decide whether our equality chains or not?

I thought the original justification for not chaining was performance: returning the original object cost more than not returning anything (i.e. returning ()).  Has that changed?

I do like chained assignment, but if there is actually a performance penalty, I'm not sure I want to pay it; and if the user gets to choose whether there's chained assignment or not, wouldn't that get confusing?  If the user does not get to choose, what about legacy code?

I think you misunderstand me.  That's not some hypothetical feature.  That's what you've always been able to do.

Ah.  Hm.  Interesting.  But it only works for x x_= pairs, not for var.  That's kind of...only half useful.  Now that you mention it, maybe I already knew this.  It's easy to forget these things when they're not default behavior, and when I have internally decided that = does not return this, while := does (personal convention for mutable wrappers).

  --Rex

Cool!

We could even avoid the automatically generated setter/getter for _x if using the "private[this]"
modifier.

Consider:

before:
-------

scala> class A[T](init: T) {private var _x = init; def x = _x; def x_=(y: T): T = {_x = y ; y}}
defined class A

scala> :javap -private A
Compiled from ""
public class A extends java.lang.Object implements scala.ScalaObject{
private java.lang.Object _x;
private java.lang.Object _x();
private void _x_$eq(java.lang.Object);
public java.lang.Object x();
public java.lang.Object x_$eq(java.lang.Object);
public A(java.lang.Object);
}

after:
------

scala> class A[T](init: T) {private[this] var _x = init; def x = _x; def x_=(y: T): T = {_x = y; y}}
defined class A

scala> :javap -private A
Compiled from ""
public class A extends java.lang.Object implements scala.ScalaObject{
private java.lang.Object _x;
public java.lang.Object x();
public java.lang.Object x_$eq(java.lang.Object);
public A(java.lang.Object);
}

On 2011-12-23 22:46, Rex Kerr wrote:
> Ah. Hm. Interesting. But it only works for x x_= pairs, not for var. That's kind of...only half
> useful.

In order to use that with vars:

Why not to allow users to define own setters, in which case the compiler should not generate the
default setter? (In analogy to the compiler generated default constructors in Java.)

Finally I can do

while((line = in.readLine()) != null)

:)

Iterator continually in.readLine() takeWhile (_ != null)

On 24 Dec 2011, at 02:34, Eugen Labun wrote:

> Finally I can do
>
> while((line = in.readLine()) != null)
>
> :)