Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33551 > unrolled thread

Re: Assignment or Initialization?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Assignment or Initialization? 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-01 19:03 +0000
    Re: Assignment or Initialization? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-01 14:47 -0500
      Re: Assignment or Initialization? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-02-01 12:31 -0800
        Re: Assignment or Initialization? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-01 16:03 -0500
          Re: Assignment or Initialization? Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-01 19:52 -0500
            Re: Assignment or Initialization? Arne Vajhøj <arne@vajhoej.dk> - 2016-02-01 20:46 -0500
            Re: Assignment or Initialization? Wayne <nospam@all.invalid> - 2016-02-01 23:39 -0500
              Re: Assignment or Initialization? Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-02 09:14 -0500
        Re: Assignment or Initialization? 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-02 19:25 +0000
    Re: Assignment or Initialization? Eric Douglas <e.d.programmer@gmail.com> - 2016-02-01 13:13 -0800
      Re: Assignment or Initialization? 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-02 19:26 +0000
    Re: Assignment or Initialization? Arne Vajhøj <arne@vajhoej.dk> - 2016-02-01 20:55 -0500
      Re: Assignment or Initialization? 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-02 19:29 +0000
        Re: Assignment or Initialization? Eric Douglas <e.d.programmer@gmail.com> - 2016-02-02 11:44 -0800
          Re: Assignment or Initialization? Lew <lewbloch@gmail.com> - 2016-02-02 13:16 -0800
        Re: Assignment or Initialization? Lew <lewbloch@gmail.com> - 2016-02-02 13:15 -0800
        Re: Assignment or Initialization? Arne Vajhøj <arne@vajhoej.dk> - 2016-02-02 18:13 -0500
        Re: Assignment or Initialization? Silvio <silvio@internet.com> - 2016-02-03 12:10 +0100
          Re: Assignment or Initialization? Eric Douglas <e.d.programmer@gmail.com> - 2016-02-03 05:14 -0800
            Re: Assignment or Initialization? Lew <lewbloch@gmail.com> - 2016-02-03 13:39 -0800
    Re: Assignment or Initialization? Lew <lewbloch@gmail.com> - 2016-02-02 10:32 -0800
      Re: Assignment or Initialization? 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-02 19:22 +0000
    Re: Assignment or Initialization? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-02-03 09:03 -0800

Page 1 of 2  [1] 2  Next page →

#33551 — Re: Assignment or Initialization?

On 01/02/2016 12:23, Stefan Ram wrote:

[...]
> final int i;
> i = 3;

This is illegal.

final int i = 3;

is the correct form: initialization. You can't declare a final variable 
and THEN assign a value to it, unless you are in a constructor, in which 
case it's still an initialization.

-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

[toc] | [next] | [standalone]

#33552

On 2/1/2016 2:03 PM, 4ndre4 wrote:
> On 01/02/2016 12:23, Stefan Ram wrote:
>
> [...]
>> final int i;
>> i = 3;
>
> This is illegal.
>
> final int i = 3;
>
> is the correct form: initialization. You can't declare a final variable
> and THEN assign a value to it, unless you are in a constructor, in which
> case it's still an initialization.

     What you say is true (I think) if `i' is a class member.
But it's untrue for local variables, where constructs like

             final boolean leftClick;
             switch (mouseEvent.getButton()) {
                case MouseEvent.BUTTON1:
                   leftClick = true;
                   break;
                case MouseEvent.BUTTON3:
                   leftClick = false;
                   break;
                default:
                   // Unidentifiable mouse button: Ignore.
                   return;
             }

... work exactly as one would expect: `leftClick' is given only
one value and is thereafter immutable, but the value comes from one
of two (in this case) assignment statements.

     Whether this is counts as an "assignment" or as an "initialization"
is not something I lose sleep over.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33553

On 2/1/2016 11:47, Eric Sosman wrote:
> On 2/1/2016 2:03 PM, 4ndre4 wrote:
>> On 01/02/2016 12:23, Stefan Ram wrote:
>>
>> [...]
>>> final int i;
>>> i = 3;
>>
>> This is illegal.
>>
>> final int i = 3;
>>
>> is the correct form: initialization. You can't declare a final variable
>> and THEN assign a value to it, unless you are in a constructor, in which
>> case it's still an initialization.
>
>      What you say is true (I think) if `i' is a class member.
> But it's untrue for local variables, where constructs like
>
>              final boolean leftClick;
>              switch (mouseEvent.getButton()) {
>                 case MouseEvent.BUTTON1:
>                    leftClick = true;
>                    break;
>                 case MouseEvent.BUTTON3:
>                    leftClick = false;
>                    break;
>                 default:
>                    // Unidentifiable mouse button: Ignore.
>                    return;
>              }
>
> ... work exactly as one would expect: `leftClick' is given only
> one value and is thereafter immutable, but the value comes from one
> of two (in this case) assignment statements.
>
>      Whether this is counts as an "assignment" or as an "initialization"
> is not something I lose sleep over.
>

public class test {
     final int i;

     public test() {
         i = 666;
     }
}

is perfectly legal and used all the time (by me anyway).


-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#33554

On 2/1/2016 3:31 PM, Knute Johnson wrote:
> On 2/1/2016 11:47, Eric Sosman wrote:
>> On 2/1/2016 2:03 PM, 4ndre4 wrote:
>>> On 01/02/2016 12:23, Stefan Ram wrote:
>>>
>>> [...]
>>>> final int i;
>>>> i = 3;
>>>
>>> This is illegal.
>>>
>>> final int i = 3;
>>>
>>> is the correct form: initialization. You can't declare a final variable
>>> and THEN assign a value to it, unless you are in a constructor, in which
>>> case it's still an initialization.
>>
>>      What you say is true (I think) if `i' is a class member.
>> But it's untrue for local variables, where constructs like
>>
>>              final boolean leftClick;
>>              switch (mouseEvent.getButton()) {
>>                 case MouseEvent.BUTTON1:
>>                    leftClick = true;
>>                    break;
>>                 case MouseEvent.BUTTON3:
>>                    leftClick = false;
>>                    break;
>>                 default:
>>                    // Unidentifiable mouse button: Ignore.
>>                    return;
>>              }
>>
>> ... work exactly as one would expect: `leftClick' is given only
>> one value and is thereafter immutable, but the value comes from one
>> of two (in this case) assignment statements.
>>
>>      Whether this is counts as an "assignment" or as an "initialization"
>> is not something I lose sleep over.
>>
>
> public class test {
>      final int i;
>
>      public test() {
>          i = 666;
>      }
> }
>
> is perfectly legal and used all the time (by me anyway).

     That's the case 4ndre4  described: Initialization of a final
field in a constructor.  But 4ndre4 seemed to be saying that it's
the only legal case, and my point was that there are others.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33556

On 2/1/2016 4:03 PM, Eric Sosman wrote:
> On 2/1/2016 3:31 PM, Knute Johnson wrote:
>> On 2/1/2016 11:47, Eric Sosman wrote:
>>> On 2/1/2016 2:03 PM, 4ndre4 wrote:
>>>> On 01/02/2016 12:23, Stefan Ram wrote:
>>>>
>>>> [...]
>>>>> final int i;
>>>>> i = 3;
>>>>
>>>> This is illegal.
>>>>
>>>> final int i = 3;
>>>>
>>>> is the correct form: initialization. You can't declare a final variable
>>>> and THEN assign a value to it, unless you are in a constructor, in
>>>> which
>>>> case it's still an initialization.
>>>
>>>      What you say is true (I think) if `i' is a class member.
>>> But it's untrue for local variables, where constructs like
>>>
>>>              final boolean leftClick;
>>>              switch (mouseEvent.getButton()) {
>>>                 case MouseEvent.BUTTON1:
>>>                    leftClick = true;
>>>                    break;
>>>                 case MouseEvent.BUTTON3:
>>>                    leftClick = false;
>>>                    break;
>>>                 default:
>>>                    // Unidentifiable mouse button: Ignore.
>>>                    return;
>>>              }
>>>
>>> ... work exactly as one would expect: `leftClick' is given only
>>> one value and is thereafter immutable, but the value comes from one
>>> of two (in this case) assignment statements.
>>>
>>>      Whether this is counts as an "assignment" or as an "initialization"
>>> is not something I lose sleep over.
>>>
>>
>> public class test {
>>      final int i;
>>
>>      public test() {
>>          i = 666;
>>      }
>> }
>>
>> is perfectly legal and used all the time (by me anyway).
> 
>     That's the case 4ndre4  described: Initialization of a final
> field in a constructor.  But 4ndre4 seemed to be saying that it's
> the only legal case, and my point was that there are others.
> 

Actually, I believe it is *assignment* in the constructor.
Initialization would be :

  public test() : i(666) {
  }


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33557

On 2/1/2016 7:52 PM, Jerry Stuckle wrote:
> On 2/1/2016 4:03 PM, Eric Sosman wrote:
>> On 2/1/2016 3:31 PM, Knute Johnson wrote:
>>> public class test {
>>>       final int i;
>>>
>>>       public test() {
>>>           i = 666;
>>>       }
>>> }
>>>
>>> is perfectly legal and used all the time (by me anyway).
>>
>>      That's the case 4ndre4  described: Initialization of a final
>> field in a constructor.  But 4ndre4 seemed to be saying that it's
>> the only legal case, and my point was that there are others.
>>
>
> Actually, I believe it is *assignment* in the constructor.
> Initialization would be :
>
>    public test() : i(666) {
>    }

The above is not in any way valid Java, so definitely no.

Arne

[toc] | [prev] | [next] | [standalone]

#33560

On 2/1/2016 7:52 PM, Jerry Stuckle wrote:
> On 2/1/2016 4:03 PM, Eric Sosman wrote:
>> On 2/1/2016 3:31 PM, Knute Johnson wrote:
>>> On 2/1/2016 11:47, Eric Sosman wrote:
>>>> On 2/1/2016 2:03 PM, 4ndre4 wrote:
>>>>> On 01/02/2016 12:23, Stefan Ram wrote:
>>>>>
>>>>> [...]
>>>>>> final int i;
>>>>>> i = 3;
>>>>>
>>>>> This is illegal.
>>>>>
>>>>> final int i = 3;
>>>>>
>>>>> is the correct form: initialization. You can't declare a final variable
>>>>> and THEN assign a value to it, unless you are in a constructor, in
>>>>> which
>>>>> case it's still an initialization.
>>>>
>>>>      What you say is true (I think) if `i' is a class member.
>>>> But it's untrue for local variables, where constructs like
>>>>
>>>>              final boolean leftClick;
>>>>              switch (mouseEvent.getButton()) {
>>>>                 case MouseEvent.BUTTON1:
>>>>                    leftClick = true;
>>>>                    break;
>>>>                 case MouseEvent.BUTTON3:
>>>>                    leftClick = false;
>>>>                    break;
>>>>                 default:
>>>>                    // Unidentifiable mouse button: Ignore.
>>>>                    return;
>>>>              }
>>>>
>>>> ... work exactly as one would expect: `leftClick' is given only
>>>> one value and is thereafter immutable, but the value comes from one
>>>> of two (in this case) assignment statements.
>>>>
>>>>      Whether this is counts as an "assignment" or as an "initialization"
>>>> is not something I lose sleep over.
>>>>
>>>
>>> public class test {
>>>      final int i;
>>>
>>>      public test() {
>>>          i = 666;
>>>      }
>>> }
>>>
>>> is perfectly legal and used all the time (by me anyway).
>>
>>     That's the case 4ndre4  described: Initialization of a final
>> field in a constructor.  But 4ndre4 seemed to be saying that it's
>> the only legal case, and my point was that there are others.
>>
> 
> Actually, I believe it is *assignment* in the constructor.
> Initialization would be :
> 
>   public test() : i(666) {
>   }
> 
> 

That's in C++, not Java!

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#33561

On 2/1/2016 11:39 PM, Wayne wrote:
> On 2/1/2016 7:52 PM, Jerry Stuckle wrote:
>> On 2/1/2016 4:03 PM, Eric Sosman wrote:
>>> On 2/1/2016 3:31 PM, Knute Johnson wrote:
>>>> On 2/1/2016 11:47, Eric Sosman wrote:
>>>>> On 2/1/2016 2:03 PM, 4ndre4 wrote:
>>>>>> On 01/02/2016 12:23, Stefan Ram wrote:
>>>>>>
>>>>>> [...]
>>>>>>> final int i;
>>>>>>> i = 3;
>>>>>>
>>>>>> This is illegal.
>>>>>>
>>>>>> final int i = 3;
>>>>>>
>>>>>> is the correct form: initialization. You can't declare a final variable
>>>>>> and THEN assign a value to it, unless you are in a constructor, in
>>>>>> which
>>>>>> case it's still an initialization.
>>>>>
>>>>>      What you say is true (I think) if `i' is a class member.
>>>>> But it's untrue for local variables, where constructs like
>>>>>
>>>>>              final boolean leftClick;
>>>>>              switch (mouseEvent.getButton()) {
>>>>>                 case MouseEvent.BUTTON1:
>>>>>                    leftClick = true;
>>>>>                    break;
>>>>>                 case MouseEvent.BUTTON3:
>>>>>                    leftClick = false;
>>>>>                    break;
>>>>>                 default:
>>>>>                    // Unidentifiable mouse button: Ignore.
>>>>>                    return;
>>>>>              }
>>>>>
>>>>> ... work exactly as one would expect: `leftClick' is given only
>>>>> one value and is thereafter immutable, but the value comes from one
>>>>> of two (in this case) assignment statements.
>>>>>
>>>>>      Whether this is counts as an "assignment" or as an "initialization"
>>>>> is not something I lose sleep over.
>>>>>
>>>>
>>>> public class test {
>>>>      final int i;
>>>>
>>>>      public test() {
>>>>          i = 666;
>>>>      }
>>>> }
>>>>
>>>> is perfectly legal and used all the time (by me anyway).
>>>
>>>     That's the case 4ndre4  described: Initialization of a final
>>> field in a constructor.  But 4ndre4 seemed to be saying that it's
>>> the only legal case, and my point was that there are others.
>>>
>>
>> Actually, I believe it is *assignment* in the constructor.
>> Initialization would be :
>>
>>   public test() : i(666) {
>>   }
>>
>>
> 
> That's in C++, not Java!
> 

True - been doing too much of both lately! :)


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33564

On 01/02/2016 20:31, Knute Johnson wrote:
[...]
>>      What you say is true (I think) if `i' is a class member.

What I had in mind when I wrote that was the re-assignment of a 
variable, not the first assignment of a final variable, and I expressed 
that incorrectly. It is indeed legal to declare a final variable and 
then assign a value to it, but because you can assign that value only 
once, it's actually an initialization, not an assignment.


-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

[toc] | [prev] | [next] | [standalone]

#33555

On Monday, February 1, 2016 at 2:04:09 PM UTC-5, 4ndre4 wrote:
> On 01/02/2016 12:23, Stefan Ram wrote:
> 
> [...]
> > final int i;
> > i = 3;
> 
> This is illegal.

Why would that be illegal, and was there a point to this?  I read this on Google Groups and somehow don't get anything Stefan Ram posts to it.
It is common practice to declare a variable as final and not assign it a value.  Normally you do that where it could have different values, with an if/else or switch structure.  As long as every possible condition gives it exactly one value it's fine.

[toc] | [prev] | [next] | [standalone]

#33565

On 01/02/2016 21:13, Eric Douglas wrote:
[...]
> Why would that be illegal, and was there a point to this?
 >It is common practice to declare a variable as final and not assign it 
a value.

You are right, and what I wrote was wrong. What I had in my was the 
re-assignment, not the first assignment. Sorry for the confusion.

-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

[toc] | [prev] | [next] | [standalone]

#33558

On 2/1/2016 2:03 PM, 4ndre4 wrote:
> On 01/02/2016 12:23, Stefan Ram wrote:
> [...]
>> final int i;
>> i = 3;
>
> This is illegal.

No. It is valid Java.

> final int i = 3;
>
> is the correct form: initialization.

Both forms are correct (assuming correct means: valid syntax and
well defined semantics).

In this particular case it is the best form.

Bit in more complex cases with if and switch then the original form
becomes necessary.

>                                     You can't declare a final variable
> and THEN assign a value to it, unless you are in a constructor, in which
> case it's still an initialization.

No. That is not how Java is.

In fact the JLS section about final start with:

"Once a final variable has been assigned, it always contains the same 
value."

so final variables do get assigned (in Java terminology).

Ref:

https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.12.4

Arne

[toc] | [prev] | [next] | [standalone]

#33566

On 02/02/2016 01:55, Arne Vajhøj wrote:

[...]
>>                                     You can't declare a final variable
>> and THEN assign a value to it, unless you are in a constructor, in which
>> case it's still an initialization.
>
> No. That is not how Java is.
>
> In fact the JLS section about final start with:
>
> "Once a final variable has been assigned, it always contains the same
> value."
>
> so final variables do get assigned (in Java terminology).

Although you are right on the first point - you can indeed declare a 
final variable and then assing a value to it, the question of the OP was 
around initialization vs. assignment. I see the first assignment to a 
final variable as an initialization, not an assignment. If we consider 
the question in those terms, you can't really assign a value to a final 
variable, you can only initialize it.

 >so final variables do get assigned

No, they get initialized.

-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

[toc] | [prev] | [next] | [standalone]

#33567

On Tuesday, February 2, 2016 at 2:29:25 PM UTC-5, 4ndre4 wrote:
>  >so final variables do get assigned
> 
> No, they get initialized.

I think the confusion now is normally no one talks about initializing primitive variables, it's just assignment whether it's the first value assigned or the fifth.  Initialize is normally only relevant in the constructor of an object.

I can have an object that looks like this.
public class Obj {
private int val;
public Obj() {
val = 1;
}
public void setVal(final int newval) {
val = newval;
}
}

Then I initialize it to 1.
final Obj MyObj = new Obj();

Then I assign it.
MyObj.setVal(2);

[toc] | [prev] | [next] | [standalone]

#33569

On Tuesday, February 2, 2016 at 11:44:19 AM UTC-8, Eric Douglas wrote:
> On Tuesday, February 2, 2016 at 2:29:25 PM UTC-5, 4ndre4 wrote:
> >  >so final variables do get assigned
> > 
> > No, they get initialized.
> 
> I think the confusion now is normally no one talks about initializing primitive variables, it's just assignment whether it's the first value assigned or the fifth.  Initialize is normally only relevant in the constructor of an object.

Initialization applies to local variables, not just within constructors.

[toc] | [prev] | [next] | [standalone]

#33568

On Tuesday, February 2, 2016 at 11:29:25 AM UTC-8, 4ndre4 wrote:
> On 02/02/2016 01:55, Arne Vajhøj wrote:
> 
> [...]
> >>                                     You can't declare a final variable
> >> and THEN assign a value to it, unless you are in a constructor, in which
> >> case it's still an initialization.
> >
> > No. That is not how Java is.
> >
> > In fact the JLS section about final start with:
> >
> > "Once a final variable has been assigned, it always contains the same
> > value."
> >
> > so final variables do get assigned (in Java terminology).
> 
> Although you are right on the first point - you can indeed declare a 
> final variable and then assing a value to it, the question of the OP was 
> around initialization vs. assignment. I see the first assignment to a 
> final variable as an initialization, not an assignment. If we consider 
> the question in those terms, you can't really assign a value to a final 
> variable, you can only initialize it.
> 
>  >so final variables do get assigned
> 
> No, they get initialized.

Since the JLS *defines* the Java language, its statements and definitions are normative:
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-16.html>
"Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs."

Hmm, they call it "assigned".

"... every blank final variable must be assigned at most once; it must be definitely unassigned when an assignment to it occurs."

There it is again.

"For every assignment to a blank final variable, the variable must be definitely unassigned before the assignment, or a compile-time error occurs." (in boldface in the original)

They call it "assignment", in boldface no less.

"... assignment to the local variable or blank final field ..."
"Consider an assignment expression a = b, a += b, a -= b, a *= b, a /= b, a %= b, a <<= b, a >>= b, a >>>= b, a &= b, a |= b, or a ^= b ..."

Heck, the whole durn chapter is "Chapter 16. Definite Assignment"!

Furthermore, the whole class of "=" operators are called "15.26. Assignment Operators", the effect of each of which is that it "assigns the value" of the right-hand expression to the variable on the left hand. That chapter also informs us that:
"A variable that is declared final cannot be assigned to (unless it is definitely unassigned (§16 (Definite Assignment))), ..,."

Well, what about what the JLS has to say about initialization?
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.2>
"If a declarator in a field declaration has a variable initializer, then the declarator has the semantics of an assignment (§15.26) to the declared variable."
and
"At run time, the initializer is evaluated and *the assignment* performed exactly once, when the class is initialized (§12.4.2)." [emph. added]
"At run time, the initializer is evaluated and *the assignment* performed each time an instance of the class is created (§12.5)." [emph. added]

So again, the JLS calls it "assignment", even when it is also an initialization.

You should, too.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33570

On 2/2/2016 2:29 PM, 4ndre4 wrote:
> On 02/02/2016 01:55, Arne Vajhøj wrote:
>
> [...]
>>>                                     You can't declare a final variable
>>> and THEN assign a value to it, unless you are in a constructor, in which
>>> case it's still an initialization.
>>
>> No. That is not how Java is.
>>
>> In fact the JLS section about final start with:
>>
>> "Once a final variable has been assigned, it always contains the same
>> value."
>>
>> so final variables do get assigned (in Java terminology).
>
> Although you are right on the first point - you can indeed declare a
> final variable and then assing a value to it, the question of the OP was
> around initialization vs. assignment. I see the first assignment to a
> final variable as an initialization, not an assignment. If we consider
> the question in those terms, you can't really assign a value to a final
> variable, you can only initialize it.
>
>  >so final variables do get assigned
>
> No, they get initialized.

I quoted the Java Language specification for calling it assignment.

So let me ask you: do you not believe it is correctly quoted or do you
consider your opinion to take precedence over the language
specification regarding what is the correct terminology????

Arne

[toc] | [prev] | [next] | [standalone]

#33573

On 02/02/2016 08:29 PM, 4ndre4 wrote:
> On 02/02/2016 01:55, Arne Vajhøj wrote:
>
> [...]
>>>                                     You can't declare a final variable
>>> and THEN assign a value to it, unless you are in a constructor, in which
>>> case it's still an initialization.
>>
>> No. That is not how Java is.
>>
>> In fact the JLS section about final start with:
>>
>> "Once a final variable has been assigned, it always contains the same
>> value."
>>
>> so final variables do get assigned (in Java terminology).
>
> Although you are right on the first point - you can indeed declare a
> final variable and then assing a value to it, the question of the OP was
> around initialization vs. assignment. I see the first assignment to a
> final variable as an initialization, not an assignment. If we consider
> the question in those terms, you can't really assign a value to a final
> variable, you can only initialize it.
>
>  >so final variables do get assigned
>
> No, they get initialized.
>

Nonsense, that is just your wording. Even in functional languages where 
variables are by definition constants people speak of single assignment.

You can argue that there is assignment and reassignment of values, the 
latter of which is not allowed on final variables. But I do not think 
the JLS uses this term.

[toc] | [prev] | [next] | [standalone]

#33574

On Wednesday, February 3, 2016 at 6:10:32 AM UTC-5, Silvio wrote:
> Nonsense, that is just your wording. Even in functional languages where 
> variables are by definition constants people speak of single assignment.
> 
> You can argue that there is assignment and reassignment of values, the 
> latter of which is not allowed on final variables. But I do not think 
> the JLS uses this term.

Initialize is normally more for the first time a non-final variable gets assigned, like

public class Obj { 
private int val; 
public void init() {
val = Defaults.findFirstValue();
}
public void setVal(final int newval) { 
val = newval; 
} 
}

It could even technically not be the first value assigned, if perhaps your variable is an object and it's default value is a null before the init process, though the irrelevant semantics train may have run off the rails.

[toc] | [prev] | [next] | [standalone]

#33578

Eric Douglas wrote:
> Initialize is normally more for the first time a non-final variable gets assigned, like
> 
> public class Obj { 
> private int val; 
> public void init() {
> val = Defaults.findFirstValue();
> }
> public void setVal(final int newval) { 
> val = newval; 
> } 
> }
> 
> It could even technically not be the first value assigned, if perhaps your variable is an object and it's default value is a null before the init process, though the irrelevant semantics train may have run off the rails.

"Initialization" has a specific meaning in Java, and is not just any case of first assignment. For variables it refers to a declaration with a variable initializer. Initialization of member variables occurs once, at class initialization for static member variables and at instance initialization for instance member variables. Initialization of local variables, if it happens, happens at the point of declaration when there is an initialization expression.

All these variable initializations are also assignments. 

Assignments that occur later are not initializations.

JLS 14.4.2: "If a declarator does not have an initializer, then every reference to the variable must be preceded by execution of an assignment to the variable, or a compile-time error occurs by the rules of §16 (Definite Assignment)."

-- 
Lew

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web