Question about constructor logic

class MyClass private(field1: String, field2: String) {
def this(f: String) = f.toUpperCase match { case s =>
this(s.substring(0, 4), s.substring(4)) }
}

Could easily be wrong, I just nuked my Scala install so I can't test it.

> Now in Scala I would write
>
> class MyClass(f : String)
> {
>  private val upper = f.toUpperCase
>  private val field1 = upper.substring(0,4)
>  private val field2 = upper.substring(4)
>  def displayName = field1 + "/" + field2
> }
>
> So far so good. But what happens with "upper" which was a local variable to
> the constructor in Java (and therefore not part of the MyClass instance) in
> the Scala case? Will each MyClass instance hold three fields or does the
> compiler detect that "upper" is only needed temporarily?
>
> Thanks,
>
> Silvio
>
>
> --
> View this message in context: http://www.nabble.com/Question-about-constructor-logic-tp22660792p226607...
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

On Monday March 23 2009, Silvio Bierman wrote:
> One of the things I like about Scala is that a class body is executed
> as part of the construction of a class instance. This removes the
> need for explicit constructor methods. Now that I am actually writing
> a larger application in Scala one question has come up.
>
> ...
>
> So far so good. But what happens with "upper" which was a local
> variable to the constructor in Java (and therefore not part of the
> MyClass instance) in the Scala case? Will each MyClass instance hold
> three fields or does the compiler detect that "upper" is only needed
> temporarily?

The answer is "yes," unless you use a magic incantation. This came up
here just a week ago. See "Temporary Values in Constructors Retained As
Fields" in your archive or this nabble entry:

> Thanks,
>
> Silvio

Randall Schulz

Thanks,

Thanks for the link to the thread. I missed it during my scan for similar
topcis but this covers it nicely.

My personal feeling is that there should be a very simnple and convenient
mechanism to handle this. To use factory methods like was suggested in the
thread is way to awkward for something that occurs so frequently.

Since the applications we are writing in Scala currently require lots of
wiring of components in some larger hierarchy and adding event-handlers to
them a large part of our code resides in primary constructors.

Since there is no need to drastically minimize memory footprint for these
components we will ignore the incurred memory overhead for now but I am very
interested in hearing about any future solution for this.

Regards,

Silvio Bierman

Randall Schulz wrote:
>
> On Monday March 23 2009, Silvio Bierman wrote:
>> One of the things I like about Scala is that a class body is executed
>> as part of the construction of a class instance. This removes the
>> need for explicit constructor methods. Now that I am actually writing
>> a larger application in Scala one question has come up.
>>
>> ...
>>
>> So far so good. But what happens with "upper" which was a local
>> variable to the constructor in Java (and therefore not part of the
>> MyClass instance) in the Scala case? Will each MyClass instance hold
>> three fields or does the compiler detect that "upper" is only needed
>> temporarily?
>
> The answer is "yes," unless you use a magic incantation. This came up
> here just a week ago. See "Temporary Values in Constructors Retained As
> Fields" in your archive or this nabble entry:
>
>
>
>
>> Thanks,
>>
>> Silvio
>
>
> Randall Schulz
>
>

Why not have a keyword such as "local" to designate temporary vals or vars in the constructor that should not be saved as part of the class instance?

Russ P.

On Mon, Mar 23, 2009 at 7:41 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Thanks,

Thanks for the link to the thread. I missed it during my scan for similar
topcis but this covers it nicely.

My personal feeling is that there should be a very simnple and convenient
mechanism to handle this. To use factory methods like was suggested in the
thread is way to awkward for something that occurs so frequently.

Since the applications we are writing in Scala currently require lots of
wiring of components in some larger hierarchy and adding event-handlers to
them a large part of our code resides in primary constructors.

Since there is no need to drastically minimize memory footprint for these
components we will ignore the incurred memory overhead for now but I am very
interested in hearing about any future solution for this.

Regards,

Silvio Bierman



Randall Schulz wrote:
>
> On Monday March 23 2009, Silvio Bierman wrote:
>> One of the things I like about Scala is that a class body is executed
>> as part of the construction of a class instance. This removes the
>> need for explicit constructor methods. Now that I am actually writing
>> a larger application in Scala one question has come up.
>>
>> ...
>>
>> So far so good. But what happens with "upper" which was a local
>> variable to the constructor in Java (and therefore not part of the
>> MyClass instance) in the Scala case? Will each MyClass instance hold
>> three fields or does the compiler detect that "upper" is only needed
>> temporarily?
>
> The answer is "yes," unless you use a magic incantation. This came up
> here just a week ago. See "Temporary Values in Constructors Retained As
> Fields" in your archive or this nabble entry:
>
> <http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-tp22526316p22526316.html>
>
>
>> Thanks,
>>
>> Silvio
>
>
> Randall Schulz
>
>

--
View this message in context: http://www.nabble.com/Question-about-constructor-logic-tp22660792p22661499.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
http://RussP.us

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

-Arthur


On Mon, Mar 23, 2009 at 1:41 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Why not have a keyword such as "local" to designate temporary vals or vars in the constructor that should not be saved as part of the class instance?

Russ P.

On Mon, Mar 23, 2009 at 7:41 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Thanks,

Thanks for the link to the thread. I missed it during my scan for similar
topcis but this covers it nicely.

My personal feeling is that there should be a very simnple and convenient
mechanism to handle this. To use factory methods like was suggested in the
thread is way to awkward for something that occurs so frequently.

Since the applications we are writing in Scala currently require lots of
wiring of components in some larger hierarchy and adding event-handlers to
them a large part of our code resides in primary constructors.

Since there is no need to drastically minimize memory footprint for these
components we will ignore the incurred memory overhead for now but I am very
interested in hearing about any future solution for this.

Regards,

Silvio Bierman



Randall Schulz wrote:
>
> On Monday March 23 2009, Silvio Bierman wrote:
>> One of the things I like about Scala is that a class body is executed
>> as part of the construction of a class instance. This removes the
>> need for explicit constructor methods. Now that I am actually writing
>> a larger application in Scala one question has come up.
>>
>> ...
>>
>> So far so good. But what happens with "upper" which was a local
>> variable to the constructor in Java (and therefore not part of the
>> MyClass instance) in the Scala case? Will each MyClass instance hold
>> three fields or does the compiler detect that "upper" is only needed
>> temporarily?
>
> The answer is "yes," unless you use a magic incantation. This came up
> here just a week ago. See "Temporary Values in Constructors Retained As
> Fields" in your archive or this nabble entry:
>
> <http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-tp22526316p22526316.html>
>
>
>> Thanks,
>>
>> Silvio
>
>
> Randall Schulz
>
>

--
View this message in context: http://www.nabble.com/Question-about-constructor-logic-tp22660792p22661499.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
http://RussP.us

(private[this] + the variable is not used by any methods, IIRC)

On Mon, Mar 23, 2009 at 1:52 PM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

-Arthur


On Mon, Mar 23, 2009 at 1:41 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Why not have a keyword such as "local" to designate temporary vals or vars in the constructor that should not be saved as part of the class instance?

Russ P.

On Mon, Mar 23, 2009 at 7:41 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Thanks,

Thanks for the link to the thread. I missed it during my scan for similar
topcis but this covers it nicely.

My personal feeling is that there should be a very simnple and convenient
mechanism to handle this. To use factory methods like was suggested in the
thread is way to awkward for something that occurs so frequently.

Since the applications we are writing in Scala currently require lots of
wiring of components in some larger hierarchy and adding event-handlers to
them a large part of our code resides in primary constructors.

Since there is no need to drastically minimize memory footprint for these
components we will ignore the incurred memory overhead for now but I am very
interested in hearing about any future solution for this.

Regards,

Silvio Bierman



Randall Schulz wrote:
>
> On Monday March 23 2009, Silvio Bierman wrote:
>> One of the things I like about Scala is that a class body is executed
>> as part of the construction of a class instance. This removes the
>> need for explicit constructor methods. Now that I am actually writing
>> a larger application in Scala one question has come up.
>>
>> ...
>>
>> So far so good. But what happens with "upper" which was a local
>> variable to the constructor in Java (and therefore not part of the
>> MyClass instance) in the Scala case? Will each MyClass instance hold
>> three fields or does the compiler detect that "upper" is only needed
>> temporarily?
>
> The answer is "yes," unless you use a magic incantation. This came up
> here just a week ago. See "Temporary Values in Constructors Retained As
> Fields" in your archive or this nabble entry:
>
> <http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-tp22526316p22526316.html>
>
>
>> Thanks,
>>
>> Silvio
>
>
> Randall Schulz
>
>

--
View this message in context: http://www.nabble.com/Question-about-constructor-logic-tp22660792p22661499.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
http://RussP.us

Yes. However the other thread said that it is not implemented but that is should be and can be.

-Arthur


On Mon, Mar 23, 2009 at 3:26 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

(private[this] + the variable is not used by any methods, IIRC)

On Mon, Mar 23, 2009 at 1:52 PM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

-Arthur


On Mon, Mar 23, 2009 at 1:41 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Why not have a keyword such as "local" to designate temporary vals or vars in the constructor that should not be saved as part of the class instance?

Russ P.

On Mon, Mar 23, 2009 at 7:41 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Thanks,

Thanks for the link to the thread. I missed it during my scan for similar
topcis but this covers it nicely.

My personal feeling is that there should be a very simnple and convenient
mechanism to handle this. To use factory methods like was suggested in the
thread is way to awkward for something that occurs so frequently.

Since the applications we are writing in Scala currently require lots of
wiring of components in some larger hierarchy and adding event-handlers to
them a large part of our code resides in primary constructors.

Since there is no need to drastically minimize memory footprint for these
components we will ignore the incurred memory overhead for now but I am very
interested in hearing about any future solution for this.

Regards,

Silvio Bierman



Randall Schulz wrote:
>
> On Monday March 23 2009, Silvio Bierman wrote:
>> One of the things I like about Scala is that a class body is executed
>> as part of the construction of a class instance. This removes the
>> need for explicit constructor methods. Now that I am actually writing
>> a larger application in Scala one question has come up.
>>
>> ...
>>
>> So far so good. But what happens with "upper" which was a local
>> variable to the constructor in Java (and therefore not part of the
>> MyClass instance) in the Scala case? Will each MyClass instance hold
>> three fields or does the compiler detect that "upper" is only needed
>> temporarily?
>
> The answer is "yes," unless you use a magic incantation. This came up
> here just a week ago. See "Temporary Values in Constructors Retained As
> Fields" in your archive or this nabble entry:
>
> <http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-tp22526316p22526316.html>
>
>
>> Thanks,
>>
>> Silvio
>
>
> Randall Schulz
>
>

--
View this message in context: http://www.nabble.com/Question-about-constructor-logic-tp22660792p22661499.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
http://RussP.us

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

private without [this], IIRC, can be accessed from another instance of the same type. I'm not sure why this optimization requires [this], and just scanning the class body for any accesses of the field other than its own instance inside the constructor does not suffice. Maybe it's easier for the optimization not to have to worry about looking up the type of other variables to check if they are of the current class's type. In any case it's not implemented yet.
  

On Mon, Mar 23, 2009 at 4:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

I'm being slightly pedantic I know, but just to be clear:

You are partly right. "private[this]" means private to this object (only this specific instance can access it). However "private" does not mean that (and it doesn't in Java either). "private" means private to the class and other instances of the same class can access it. (see The Scala Spec 5.2 if you want more details)

-Arthur


On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

BTW, is "this" a valid type parameter in other contexts? Does classOf[this] work?

On Mon, Mar 23, 2009 at 4:21 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

private without [this], IIRC, can be accessed from another instance of the same type. I'm not sure why this optimization requires [this], and just scanning the class body for any accesses of the field other than its own instance inside the constructor does not suffice. Maybe it's easier for the optimization not to have to worry about looking up the type of other variables to check if they are of the current class's type. In any case it's not implemented yet.
  

On Mon, Mar 23, 2009 at 4:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

2009/3/23 Naftoli Gugenheim :
> BTW, is "this" a valid type parameter in other contexts? Does classOf[this]
> work?
>

No; you can also have private[some.package], and (unsurprisingly)
classOf[some.package] doesn't work either.

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

What am asking is, what's the importance of not being referred to in a method?

On Mon, Mar 23, 2009 at 5:23 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

If the variable is referred to in a method, then the variable has to be stored on the object so that the method can use it.  If the variable isn't put on the object, then the referencing method won't even compile.

On Mon, Mar 23, 2009 at 5:27 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

What am asking is, what's the importance of not being referred to in a method?

On Mon, Mar 23, 2009 at 5:23 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

So why would you want to prevent that?

On Mon, Mar 23, 2009 at 5:30 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

If the variable is referred to in a method, then the variable has to be stored on the object so that the method can use it.  If the variable isn't put on the object, then the referencing method won't even compile.

On Mon, Mar 23, 2009 at 5:27 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

What am asking is, what's the importance of not being referred to in a method?

On Mon, Mar 23, 2009 at 5:23 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

Because you're using a temporary variable, and you (1) want the object to which it refers to be GC'd when you're done, and (2) you don't want to bloat your object with extra fields.

I would classify a "local" annotation (err...keyword) in the same group with the @tailrec annotation paulp recently added to trunk.  The runtime characteristics of your program are potentially very different if the reference is retained, so you want to ensure that it isn't.  Just like a non-tail recursive method and a tail recursive method have very different characteristics.

Otherwise I think the compiler implementing the optimization would be sufficient.

On Mon, Mar 23, 2009 at 5:32 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

So why would you want to prevent that?

On Mon, Mar 23, 2009 at 5:30 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

If the variable is referred to in a method, then the variable has to be stored on the object so that the method can use it.  If the variable isn't put on the object, then the referencing method won't even compile.

On Mon, Mar 23, 2009 at 5:27 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

What am asking is, what's the importance of not being referred to in a method?

On Mon, Mar 23, 2009 at 5:23 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

Right, so if a method doesn't access the variable, you should get GC and bloatlessness implicitly, and if it does, then there's no way around it, so what do you gain by an explicit keyword or annotation?In what scenario is there not enough information for the compiler to figure out what you want?

On Mon, Mar 23, 2009 at 5:39 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Because you're using a temporary variable, and you (1) want the object to which it refers to be GC'd when you're done, and (2) you don't want to bloat your object with extra fields.

I would classify a "local" annotation (err...keyword) in the same group with the @tailrec annotation paulp recently added to trunk.  The runtime characteristics of your program are potentially very different if the reference is retained, so you want to ensure that it isn't.  Just like a non-tail recursive method and a tail recursive method have very different characteristics.

Otherwise I think the compiler implementing the optimization would be sufficient.

On Mon, Mar 23, 2009 at 5:32 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

So why would you want to prevent that?

On Mon, Mar 23, 2009 at 5:30 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

If the variable is referred to in a method, then the variable has to be stored on the object so that the method can use it.  If the variable isn't put on the object, then the referencing method won't even compile.

On Mon, Mar 23, 2009 at 5:27 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

What am asking is, what's the importance of not being referred to in a method?

On Mon, Mar 23, 2009 at 5:23 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 23, 2009 at 2:02 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why would you want that? The idea is that a constructor is as if the the class body is executable. Variables are potential fields, unless the compiler decides it can get away with optimizing them away, What's wrong with this approach?

It's not a big issue either way, but making the local nature of the variable explicit seems more or less consistent with the overall philosophy of Scala.

Why does Scala allow immutables to be explicitly declared as "val"? Because it guarantees that the value will not change. Scala does not just let the compiler figure out that the value never changes. Similarly, declaring a temp variable or value in the constructor as "local" would guarantee that it is not used anywhere outside the constructor.

Again, I don't consider this a major issue, so I'll drop it now that I've made my point.

Russ P.
 

On Mon, Mar 23, 2009 at 4:58 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

In that case, why not let the programmer explicitly declare his intent to make the variable (or val) "local" rather than letting the compiler figure it out. If you leave it to the compiler, some other programmer may come along and use the variable (not realizing that it was supposed to be local), in which case the variable is now included in every instance of the class, thus violating the intent of the original programmer.

Russ P.

On Mon, Mar 23, 2009 at 1:13 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

That is what it means, but the point is that if you tell the compiler that the "field" can only be accessed from this instance, and the compiler sees that no method is accessing it, the compiler can figure out that it can be implemented as a local variable in the constructor.

On Mon, Mar 23, 2009 at 4:07 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I don't know where the syntax "private[this]" comes from, but it seems misleading to me. If I saw it for the first time, I would assume that the variable is private to "this", which means a regular "private" variable. That's exactly what is *not* supposed to be. I think "local" makes more sense. But maybe I'm missing something.

Russ P.

On Mon, Mar 23, 2009 at 10:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

I think that keyword is not "local" but "private[this]". This is discussed a bit in the previous thread ( http://www.nabble.com/Temporary-Values-in-Constructors-Retained-As-Fields-td22526316.html#a22526316 )

--
http://RussP.us

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/