Semantics keyword "val"

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

The difference being that a final variable is still just another variable from the perspective of the JVM, it can be changed with reflection, native code, or other hackery.A C/C++ const is constant :)

On 17 October 2010 17:11, David Flemström <david.flemstrom@gmail.com> wrote:

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Unfortunately, dont know java language. How could I make mistake.
"val" assign-once. Yep more like on "const", not "static". Thanks, i will read further.  17.10.10, 22:11, "David Flemström" <david.flemstrom@gmail.com>:

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions. 

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++. 

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Sunday October 17 2010, Kevin Wright wrote:
> The difference being that a final variable is still just another
> variable from the perspective of the JVM, it can be changed with
> reflection, native code, or other hackery.
> A C/C++ const is constant :)
>
> ...

Au contraire! In C++ (C doesn't have const, does it? Or has it been
added in the many years since I've done C?) you can cast away
const-ness.

Randall Schulz

easiest possible answer:
val = cannot be changed
var = can be changed

Am 17.10.2010 18:11, schrieb David Flemström:

AANLkTimkGUpRCyNPcnWaqZQZXn-1CyUNUXTYjz04y-0_ [at] mail [dot] gmail [dot] com" type="cite">Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com" rel="nofollow">kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java. Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david [dot] flemstrom [at] gmail [dot] com" target="_blank" rel="nofollow">david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal [at] yandex [dot] ru" target="_blank" rel="nofollow">dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Failure to recognize the const_cast or volatile.....   There's even trickery in C++ to destroy any semblance of immutability in the interest of getting things done....

On Sun, Oct 17, 2010 at 12:22 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The difference being that a final variable is still just another variable from the perspective of the JVM, it can be changed with reflection, native code, or other hackery. A C/C++ const is constant :)

On 17 October 2010 17:11, David Flemström <david.flemstrom@gmail.com> wrote:

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Oh my, must be showing the rust around the edges here!Is it really that long since I've worked with C++...

On 17 October 2010 17:31, Josh Suereth <joshua.suereth@gmail.com> wrote:

Failure to recognize the const_cast or volatile.....   There's even trickery in C++ to destroy any semblance of immutability in the interest of getting things done....

On Sun, Oct 17, 2010 at 12:22 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The difference being that a final variable is still just another variable from the perspective of the JVM, it can be changed with reflection, native code, or other hackery. A C/C++ const is constant :)

On 17 October 2010 17:11, David Flemström <david.flemstrom@gmail.com> wrote:

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Well, in some cases your are still right: once the compiler has “inlined” e.g. a “const int num = 3” by using it directly in the assembler output, you cannot change it anymore, no matter how hard you try (assuming NX protection of your code segment, which I hope is the standard now). Plus, you would have to change every single use-site individually.
But concerning non-primitive values, all bets are off. Yeah, “overloading "." and ".*" is not allowed as that would change the language”, har-har, best practical joke of the previous century.
On Oct 17, 2010, at 18:34 , Kevin Wright wrote:

Oh my, must be showing the rust around the edges here!Is it really that long since I've worked with C++...

On 17 October 2010 17:31, Josh Suereth <joshua.suereth@gmail.com> wrote:

Failure to recognize the const_cast or volatile.....   There's even trickery in C++ to destroy any semblance of immutability in the interest of getting things done....

On Sun, Oct 17, 2010 at 12:22 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The difference being that a final variable is still just another variable from the perspective of the JVM, it can be changed with reflection, native code, or other hackery. A C/C++ const is constant :)

On 17 October 2010 17:11, David Flemström <david.flemstrom@gmail.com> wrote:

Yeah, the difference being that the "this-pointer" of a val isn't constant.

On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Actually, no it's not.  In bytecode it's exactly the same as variable declared final in Java.Which isn't *quite* like a const in C/C++, although the behaviour is close enough for the sake of most discussions.

On 17 October 2010 16:49, David Flemström <david.flemstrom@gmail.com> wrote:

No, it's semantically like a variable declared "const" in C/C++.

On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?


Thanks.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

You gotta be careful with simple answers :)

On 10/17/10 6:29 PM, HamsterofDeath wrote:
> easiest possible answer:
> val = cannot be changed

A val cannot be changed *after initialization*. You can override vals
and you can observe that a val holds null before it has been initialized.

Cheers,
Ingo

> var = can be changed
>
> Am 17.10.2010 18:11, schrieb David Flemström:
>> Yeah, the difference being that the "this-pointer" of a val isn't
>> constant.
>>
>> On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright
>> > wrote:
>>
>> Actually, no it's not. In bytecode it's exactly the same as
>> variable declared final in Java.
>> Which isn't *quite* like a const in C/C++, although the behaviour
>> is close enough for the sake of most discussions.
>>
>>
>> On 17 October 2010 16:49, David Flemström
>> > wrote:
>>
>> No, it's semantically like a variable declared "const" in C/C++.
>>
>>
>> On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр
>> > wrote:
>>
>> Hi.
>> I begginer in the Scala. I'm reading book "Beginning Scala".
>> My question. Declared a variable with the keyword "val"
>> semantically like a variable with the "static" keyword in
>> C + +?
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>
>> pulse / skype: kev.lee.wright
>> twitter: @thecoda
>>
>>
>

Am 17.10.2010 21:05, schrieb Ingo Maier:
> You gotta be careful with simple answers :)
>
> On 10/17/10 6:29 PM, HamsterofDeath wrote:
>> easiest possible answer:
>> val = cannot be changed
>
> A val cannot be changed *after initialization*.

if you change it before, you do not *change* but *initialize* it :)

yeah i know there are hack and whatever, but simple answers are right in
98% of all cases, that's enough to begin with.

> You can override vals and you can observe that a val holds null before
> it has been initialized.
>
> Cheers,
> Ingo
>
>> var = can be changed
>>
>> Am 17.10.2010 18:11, schrieb David Flemström:
>>> Yeah, the difference being that the "this-pointer" of a val isn't
>>> constant.
>>>
>>> On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright
>>> > wrote:
>>>
>>> Actually, no it's not. In bytecode it's exactly the same as
>>> variable declared final in Java.
>>> Which isn't *quite* like a const in C/C++, although the behaviour
>>> is close enough for the sake of most discussions.
>>>
>>>
>>> On 17 October 2010 16:49, David Flemström
>>> >
>>> wrote:
>>>
>>> No, it's semantically like a variable declared "const" in
>>> C/C++.
>>>
>>>
>>> On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр
>>> > wrote:
>>>
>>> Hi.
>>> I begginer in the Scala. I'm reading book "Beginning
>>> Scala".
>>> My question. Declared a variable with the keyword "val"
>>> semantically like a variable with the "static" keyword in
>>> C + +?
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Kevin Wright
>>>
>>> mail / gtalk / msn : kev.lee.wright@gmail.com
>>>
>>> pulse / skype: kev.lee.wright
>>> twitter: @thecoda
>>>
>>>
>>
>
>

Perhaps, but I still run into issues with initialization order more often than I'd like...

On 17 October 2010 20:11, HamsterofDeath <h-star@gmx.de> wrote:

 Am 17.10.2010 21:05, schrieb Ingo Maier:
> You gotta be careful with simple answers :)
>
> On 10/17/10 6:29 PM, HamsterofDeath wrote:
>> easiest possible answer:
>> val = cannot be changed
>
> A val cannot be changed *after initialization*.

if you change it before, you do not *change* but *initialize* it :)

yeah i know there are hack and whatever, but simple answers are right in
98% of all cases, that's enough to begin with.

> You can override vals and you can observe that a val holds null before
> it has been initialized.
>
> Cheers,
> Ingo
>
>> var = can be changed
>>
>> Am 17.10.2010 18:11, schrieb David Flemström:
>>> Yeah, the difference being that the "this-pointer" of a val isn't
>>> constant.
>>>
>>> On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright
>>> <kev.lee.wright@gmail.com <mailto:kev.lee.wright@gmail.com>> wrote:
>>>
>>>     Actually, no it's not. In bytecode it's exactly the same as
>>>     variable declared final in Java.
>>>     Which isn't *quite* like a const in C/C++, although the behaviour
>>>     is close enough for the sake of most discussions.
>>>
>>>
>>>     On 17 October 2010 16:49, David Flemström
>>>     <david.flemstrom@gmail.com <mailto:david.flemstrom@gmail.com>>
>>> wrote:
>>>
>>>         No, it's semantically like a variable declared "const" in
>>> C/C++.
>>>
>>>
>>>         On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр
>>>         <dvigal@yandex.ru <mailto:dvigal@yandex.ru>> wrote:
>>>
>>>             Hi.
>>>             I begginer in the Scala. I'm reading book "Beginning
>>> Scala".
>>>             My question. Declared a variable with the keyword "val"
>>>             semantically like a variable with the "static" keyword in
>>>             C + +?
>>>
>>>
>>>             Thanks.
>>>
>>>
>>>
>>>
>>>
>>>     --
>>>     Kevin Wright
>>>
>>>     mail / gtalk / msn : kev.lee.wright@gmail.com
>>>     <mailto:kev.lee.wright@gmail.com>
>>>     pulse / skype: kev.lee.wright
>>>     twitter: @thecoda
>>>
>>>
>>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Sun, Oct 17, 2010 at 8:47 AM, Литвинов Александр <dvigal@yandex.ru> wrote:

 Hi.
I begginer in the Scala. I'm reading book "Beginning Scala".
My question. Declared a variable with the keyword "val" semantically like a variable with the "static" keyword in C + +?

Thanks for reading Beginning Scala!
There has been a lot of good discussion of the issue on this thread already.
In Scala, references (not variables, but references to instances of objects) may point to mutable or immutable classes.  For example, String is immutable.  Once a reference to a String is created, the underlying String will not change as long as the reference is retained (reference is like a pointer in C++.)
There are also references to mutable classes, for example java.util.Date... basically anything with a setter.  Even if the reference doesn't change, the thing that's referred to can change.
A val in Scala is a single assignment variable.  Once it's set, the reference cannot be changed during the scope of the val.  This does not mean that the thing that's referred to is immutable (e.g., you can have a val reference to a java.util.Date and the Date can change).
Does this help? 

Thanks.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

That's because you don't follow one simple rule:

• Values needed at construction time should always be supplied through the constructor, not from virtual method calls.

On Sun, Oct 17, 2010 at 2:18 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Perhaps, but I still run into issues with initialization order more often than I'd like...

On 17 October 2010 20:11, HamsterofDeath <h-star@gmx.de> wrote:

 Am 17.10.2010 21:05, schrieb Ingo Maier:
> You gotta be careful with simple answers :)
>
> On 10/17/10 6:29 PM, HamsterofDeath wrote:
>> easiest possible answer:
>> val = cannot be changed
>
> A val cannot be changed *after initialization*.

if you change it before, you do not *change* but *initialize* it :)

yeah i know there are hack and whatever, but simple answers are right in
98% of all cases, that's enough to begin with.

> You can override vals and you can observe that a val holds null before
> it has been initialized.
>
> Cheers,
> Ingo
>
>> var = can be changed
>>
>> Am 17.10.2010 18:11, schrieb David Flemström:
>>> Yeah, the difference being that the "this-pointer" of a val isn't
>>> constant.
>>>
>>> On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright
>>> <kev.lee.wright@gmail.com <mailto:kev.lee.wright@gmail.com>> wrote:
>>>
>>>     Actually, no it's not. In bytecode it's exactly the same as
>>>     variable declared final in Java.
>>>     Which isn't *quite* like a const in C/C++, although the behaviour
>>>     is close enough for the sake of most discussions.
>>>
>>>
>>>     On 17 October 2010 16:49, David Flemström
>>>     <david.flemstrom@gmail.com <mailto:david.flemstrom@gmail.com>>
>>> wrote:
>>>
>>>         No, it's semantically like a variable declared "const" in
>>> C/C++.
>>>
>>>
>>>         On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр
>>>         <dvigal@yandex.ru <mailto:dvigal@yandex.ru>> wrote:
>>>
>>>             Hi.
>>>             I begginer in the Scala. I'm reading book "Beginning
>>> Scala".
>>>             My question. Declared a variable with the keyword "val"
>>>             semantically like a variable with the "static" keyword in
>>>             C + +?
>>>
>>>
>>>             Thanks.
>>>
>>>
>>>
>>>
>>>
>>>     --
>>>     Kevin Wright
>>>
>>>     mail / gtalk / msn : kev.lee.wright@gmail.com
>>>     <mailto:kev.lee.wright@gmail.com>
>>>     pulse / skype: kev.lee.wright
>>>     twitter: @thecoda
>>>
>>>
>>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...

On 17 October 2010 23:27, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

That's because you don't follow one simple rule:

• Values needed at construction time should always be supplied through the constructor, not from virtual method calls.

On Sun, Oct 17, 2010 at 2:18 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Perhaps, but I still run into issues with initialization order more often than I'd like...

On 17 October 2010 20:11, HamsterofDeath <h-star@gmx.de> wrote:

 Am 17.10.2010 21:05, schrieb Ingo Maier:
> You gotta be careful with simple answers :)
>
> On 10/17/10 6:29 PM, HamsterofDeath wrote:
>> easiest possible answer:
>> val = cannot be changed
>
> A val cannot be changed *after initialization*.

if you change it before, you do not *change* but *initialize* it :)

yeah i know there are hack and whatever, but simple answers are right in
98% of all cases, that's enough to begin with.

> You can override vals and you can observe that a val holds null before
> it has been initialized.
>
> Cheers,
> Ingo
>
>> var = can be changed
>>
>> Am 17.10.2010 18:11, schrieb David Flemström:
>>> Yeah, the difference being that the "this-pointer" of a val isn't
>>> constant.
>>>
>>> On Sun, Oct 17, 2010 at 5:58 PM, Kevin Wright
>>> <kev.lee.wright@gmail.com <mailto:kev.lee.wright@gmail.com>> wrote:
>>>
>>>     Actually, no it's not. In bytecode it's exactly the same as
>>>     variable declared final in Java.
>>>     Which isn't *quite* like a const in C/C++, although the behaviour
>>>     is close enough for the sake of most discussions.
>>>
>>>
>>>     On 17 October 2010 16:49, David Flemström
>>>     <david.flemstrom@gmail.com <mailto:david.flemstrom@gmail.com>>
>>> wrote:
>>>
>>>         No, it's semantically like a variable declared "const" in
>>> C/C++.
>>>
>>>
>>>         On Sun, Oct 17, 2010 at 5:47 PM, Литвинов Александр
>>>         <dvigal@yandex.ru <mailto:dvigal@yandex.ru>> wrote:
>>>
>>>             Hi.
>>>             I begginer in the Scala. I'm reading book "Beginning
>>> Scala".
>>>             My question. Declared a variable with the keyword "val"
>>>             semantically like a variable with the "static" keyword in
>>>             C + +?
>>>
>>>
>>>             Thanks.
>>>
>>>
>>>
>>>
>>>
>>>     --
>>>     Kevin Wright
>>>
>>>     mail / gtalk / msn : kev.lee.wright@gmail.com
>>>     <mailto:kev.lee.wright@gmail.com>
>>>     pulse / skype: kev.lee.wright
>>>     twitter: @thecoda
>>>
>>>
>>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...

That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.

On Mon, Oct 18, 2010 at 9:28 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...

That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.

Could you elaborate? What do you mean, ask for it as a constructor argument? How does that solve the case where a class or trait needs to act on its contents immediately?

On Mon, Oct 18, 2010 at 4:46 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Could you elaborate? What do you mean, ask for it as a constructor argument? How does that solve the case where a class or trait needs to act on its contents immediately?

Not sure how to elaborate. Perhaps you can provide an example of this problem?

to elaborate more on what naftoli is going after, what about a case like this:

trait MyTrait {
  val name: String
  // do something with name in constructor
}

you can't really pass the name argument to the MyTrait constructor

i think the real problem here is that you should not be using fields like name in the superclass constructor, since this code runs before initialization of your subclasses.

On Mon, Oct 18, 2010 at 2:55 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Mon, Oct 18, 2010 at 4:46 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Could you elaborate? What do you mean, ask for it as a constructor argument? How does that solve the case where a class or trait needs to act on its contents immediately?

Not sure how to elaborate. Perhaps you can provide an example of this problem?

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

Constructor parameters won't help here, as traits can't have them.

The only solutions are to use one of the early initializer syntaxes or
to make the concrete member lazy. A lazy val is initiallised
on-demand, in this case it'll, ironically, be initiallised before an
equivalent strict val would.

On Monday, October 18, 2010, Nils Kilden-Pedersen wrote:
> On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright wrote:
>
>
> I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...
> That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.
>
>
>
>

Right, but lazy vals require a much more verbose syntax, which is not so desirable for DSLs.What I would prefer to an early initialize syntax is a run late syntax. Because if the code the superclass needs to run late is going into a (not abstract) definition, it could make that a lazy val. But if you need something imperative to happen, that doesn't help. So it would be nice to write, trait MyTrait { 
  val name: String  lazy {
    // do something with name in constructor   }
}

This would not require a new keyword, and the meaning would be similar to the keyword's existing usage, except that obviously it doesn't wait to be referenced; instead it waits until everything else is initialized. Trait linearization could determine the order lazy blocks are executed. And if you need something available in a member but precomputed late, you could make it a lazy val, and then reference the lazy val in a 'lazy' block.


On Mon, Oct 18, 2010 at 6:08 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

Constructor parameters won't help here, as traits can't have them.

The only solutions are to use one of the early initializer syntaxes or
to make the concrete member lazy.  A lazy val is initiallised
on-demand, in this case it'll, ironically, be initiallised before an
equivalent strict val would.




On Monday, October 18, 2010, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
>
>
> I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...
> That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.
>
>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Oh wow, deja-vu!
Discussions about early/late initialisation (both distinct concepts from lazy initialisation) have come up before... more than once...Much was said, ideas were discussed, syntax suggested, and samples offered for debate.
Ultimately however, the sticking point was nothing to do with initialisation order, and everything to do with syntax.  Your exact proposal (lazy { ... } blocks) is something that's come up before, but proved controversial as it would introduce an entirely new concept into the language.
More specifically, *anything* currently defined within { braces } uses them as a containing scope, whereas anything defined within an "early { ... }" block would have to leak out into the scope of the containing class.  This would be unique within Scala.
We never got much further than that point...


On 18 October 2010 23:46, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Right, but lazy vals require a much more verbose syntax, which is not so desirable for DSLs.What I would prefer to an early initialize syntax is a run late syntax. Because if the code the superclass needs to run late is going into a (not abstract) definition, it could make that a lazy val. But if you need something imperative to happen, that doesn't help. So it would be nice to write, trait MyTrait { 
  val name: String  lazy {
    // do something with name in constructor   }
}

This would not require a new keyword, and the meaning would be similar to the keyword's existing usage, except that obviously it doesn't wait to be referenced; instead it waits until everything else is initialized. Trait linearization could determine the order lazy blocks are executed. And if you need something available in a member but precomputed late, you could make it a lazy val, and then reference the lazy val in a 'lazy' block.


On Mon, Oct 18, 2010 at 6:08 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

Constructor parameters won't help here, as traits can't have them.

The only solutions are to use one of the early initializer syntaxes or
to make the concrete member lazy.  A lazy val is initiallised
on-demand, in this case it'll, ironically, be initiallised before an
equivalent strict val would.




On Monday, October 18, 2010, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
>
>
> I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...
> That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.
>
>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I just described an approach that does not require leaking scope.When you write a lazy code block, it's as if the lazy keyword were a method with the signaturedef lazy(code: =>Unit): Unit In other words, nothing escapes.If you need something to escape and be evaluated late but not too late, you can use a multi-pronged approach. Make the identifier a lazy val, and reference it in a lazy block.

On Mon, Oct 18, 2010 at 7:31 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Oh wow, deja-vu!
Discussions about early/late initialisation (both distinct concepts from lazy initialisation) have come up before... more than once...Much was said, ideas were discussed, syntax suggested, and samples offered for debate.
Ultimately however, the sticking point was nothing to do with initialisation order, and everything to do with syntax.  Your exact proposal (lazy { ... } blocks) is something that's come up before, but proved controversial as it would introduce an entirely new concept into the language.
More specifically, *anything* currently defined within { braces } uses them as a containing scope, whereas anything defined within an "early { ... }" block would have to leak out into the scope of the containing class.  This would be unique within Scala.
We never got much further than that point...


On 18 October 2010 23:46, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Right, but lazy vals require a much more verbose syntax, which is not so desirable for DSLs.What I would prefer to an early initialize syntax is a run late syntax. Because if the code the superclass needs to run late is going into a (not abstract) definition, it could make that a lazy val. But if you need something imperative to happen, that doesn't help. So it would be nice to write, trait MyTrait { 
  val name: String  lazy {
    // do something with name in constructor   }
}

This would not require a new keyword, and the meaning would be similar to the keyword's existing usage, except that obviously it doesn't wait to be referenced; instead it waits until everything else is initialized. Trait linearization could determine the order lazy blocks are executed. And if you need something available in a member but precomputed late, you could make it a lazy val, and then reference the lazy val in a 'lazy' block.


On Mon, Oct 18, 2010 at 6:08 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

Constructor parameters won't help here, as traits can't have them.

The only solutions are to use one of the early initializer syntaxes or
to make the concrete member lazy.  A lazy val is initiallised
on-demand, in this case it'll, ironically, be initiallised before an
equivalent strict val would.




On Monday, October 18, 2010, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 7:15 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
>
>
> I was thinking, specifically, of the case where you mix-in a trait with an abstract variable...
> That's only is a problem if the class extending the trait attempts to access that abstract variable in the constructor. It shouldn't, but instead ask for it as a constructor argument.
>
>
>
>

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Mon, Oct 18, 2010 at 5:08 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

I guess I've never used traits that way. Seems intuitively wrong to me.

It's used heavily in the compiler, for example, where you'll find a LOT of class with an abstract `global` member.Then in the Global class itself, you'll find a whole pageful of these:
  object analyzer extends {    val global: Global.this.type = Global.this  } with Analyzer
causing the `global` val to be initialised early.
Really, this is just another twist on DI and our old friend - the cake pattern.Nothing to be scared of then, but it can lead to tight-coupling unless you take care...

On 19 October 2010 05:53, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Mon, Oct 18, 2010 at 5:08 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The real issue occurs when a trait's constructor attempts to use its
own abstract member val; a value that won't be initialized until the
constructor of the concrete subclass has run.

I guess I've never used traits that way. Seems intuitively wrong to me.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

W dniu 2010-10-19 06:53, Nils Kilden-Pedersen pisze:
> On Mon, Oct 18, 2010 at 5:08 PM, Kevin Wright
> > wrote:
>
> The real issue occurs when a trait's constructor attempts to use its
> own abstract member val; a value that won't be initialized until the
> constructor of the concrete subclass has run.
>
>
> I guess I've never used traits that way. Seems intuitively wrong to me.
>

I happened to use it this way and I'm not sure if it can be done better.
We build a circuit simulator, where electrical models are defined as
Scala classes / traits. E.g. We have several VoltageSource models, so
the common part has been moved to the trait:

trait AbstractVoltageSource extends Model with ModelReflection {

def id: Id
def voltage: Expression[DoubleWithError]

@ModelTerminal("1")
val _1 = Terminal(id.subId("1"))

@ModelTerminal("2")
val _2 = Terminal(id.subId("2"))

@ModelEquation
lazy val eq1 = _1.voltage - _2.voltage - voltage

@ModelEquation
lazy val eq2 = _1.current + _2.current

}

Now the implementations of concrete voltage sources are very simple.
E.g. a sine-wave alternating voltage source:

case class SineVoltageSource(
id: Id,

@ModelParam("amplitude")
@PhysicalUnit("V")
amplitude: Expression[DoubleWithError],

@ModelParam("frequency")
@PhysicalUnit("Hz")
frequency: Expression[DoubleWithError],

@ModelParam("phase")
@PhysicalUnit("Rad")
phase: Expression[DoubleWithError] = 0.0) extends
AbstractVoltageSource {

val voltage = amplitude * Sin(frequency * (2.0 * math.Pi) * Time + phase)

}

The equations of the abstract model depend on the voltage function
defined in subclasses. They must be lazy vals. Otherwise, "null" would
be put into equation, where "voltage" is referenced (breaking the
simulation later). I would very appreciate if the compiler at least gave
me a warning in such case.

Regards,
Piotr Kołaczkowski