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

Groups > comp.lang.java.help > #452 > unrolled thread

Re: static final int, but constructor with (final int) arguments

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

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: static final int, but constructor with (final int) arguments Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-03-30 00:45 +0200
    Re: static final int, but constructor with (final int) arguments Lew <noone@lewscanon.com> - 2011-03-29 19:03 -0400
      Re: static final int, but constructor with (final int) arguments Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-03-30 19:05 +0200
    [OT] Re: static final int, but constructor with (final int) arguments Stanimir Stamenkov <s7an10@netscape.net> - 2011-03-30 08:24 +0300
      Re: [OT] Re: static final int, but constructor with (final int) arguments Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-03-30 19:05 +0200

#452 — Re: static final int, but constructor with (final int) arguments

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew <noone@lewscanon.com> writes:

> Merciadri Luca wrote:
>> Second, if I understand all of you well, there is no real interest in
>> defining some variable as final when you are sure that its value won't
>> change.
>
> That is very untrue.  There is a great deal of value to 'final' for
> the scenario when you won't change a value.
>
> The thing is, "when you're sure its value won't change" cannot happen
> *unless* you declare the variable 'final'.
>
> Plus there are semantic implications for concurrent programming and
> the definition of a compile-time constant.
>
> It's not so simple as "I'm sure (how?) that the value won't change."
>
>> Third, if I understand you well, it is impossible to declare a private
>> final static variable which would be defined using a constructor, even
>
> Of course.
Okay.

>> if this constructor has final (i.e. value-constant) parameters. But
>
> The finality of parameters is completely unrelated.
>
>> I'm here in the case where each instance of my class defines an object
>> whose c is the same (->  static), where c is a constant (->  final), and
>> which does not need to be accessed from other classes (->  private).
>
> What do you mean byt "is the same"?  You left out the same as what.
> What is it the same as?
Every new ClassName() creates an object so that its c is the
same. This is normal as there is only one c variable in memory, as it
is static.

> "final" and "constant" in Java are not synonyms.  There are special
> rules for constants.
>
>> I cannot understand why
>>
>> ==
>>    class Foo {
>>      private static final int c = 99;
>>
>>      public Foo(final int a, final int b) {
>>        // Stuff not assigning a value to c.
>>      }
>>    }
>> ==
>> would be okay, when
>
> Why wouldn't it be?
>
> Please answer these questions.
>
>> ==
>>    class Foo {
>>      private static final int c;
>>
>>      public Foo(final int a, final int b) {
>>        // Stuff *assigning* a value to c.
>>      }
>>    }
>> ==
>> would not be okay, because when you assign some value to c, in the
>> constructor, this value will always be the same because a and b are
>> final, and thus constants. Thus, as c has not been assigned before the
>
> Nope.  Completely not even close.  'c' is static, that means it is
> attached to the class, not an object.  It can only receive a value
> once because it's 'final'.  That once MUST happen during class
> initialization, because it's 'final'.  (That's one of the reasons "I'm
> sure it won't change" is wrong.)
As you point it, my interpretation of the final keyword was erroneous.
> Class initialization completes before you create any instance.  So 'c'
> already MUST have its value by then.
>
> When you assign it from an instance, you are assigning it waaaaay too
> late and furthermore, it could be more than once.  The compiler
> recognizes this twin calamity and barfs.
>
> 'final' does NOT mean "constant"!
Same remark. Okay then. C influence on me. shame on me!
>> constructor, it should accept some value in the constructor, and this
>> value should return an exception if something tries to modify it.
>
> Wha?  Why do you have the confidence to say "should" when you're still
> completely unfamiliar with the language?
>
> PLEASE read the Java tutorials!
Well, I wanted `it should, if I were java.' Do not worry, I do not
want to dictate rules to any java compiler. I don't want to reinvent
the rules, just to understand them. And this is a progressive learning.
>
>> Fourth, to solve my current problem, i.e. to deal correctly with a
>> constant private static int value which is assigned in a
>
> It's not constant.
>
>> final-only-parameters-depending constructor, I'm not obliged to define
>
> Final parameters are completely irrelevant.  They have no influence on
> finality of anything else.  None.
>
>> this constant as a final private static int, because the class does
>> not care about this. However, what I'm thinking about is that my `c'
>
> Classes don't "care" about anything.
>
>> is a constant value, which is the same for every instance (->  static)
>> of the class, and that does not change over time. For this last
>
> And yet you wanted to change it.
>
>> reason, I was expecting it to be declared as final, as its value is
>> not modified over time. The compiler might think that it would be
>> modified over time, but it cannot, because the constructor of the
>> class only takes final int as arguments...
>
> Again, argument finality is completely unrelated to member finality.
So, is there any reason in the context of my program to declare the
three ints coming from the CLI (once exactly) as final or not? Their
value do not change, and they are only defined once: the user makes
java myProgram 1 2 3, and then each argument is kept in some
variable. I consider that this variable should be static, as the user
is never invited to type any other stuff in the CLI.

>> Before criticizing a man, walk a mile in his shoes.
>
> That way, when he gets angry you're a mile away, and you have his shoes.
Funny!!

- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

Better late than never.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2SYRoACgkQM0LLzLt8MhxbuwCfRxZbcT2C4b6co0EVrGWH4M7j
HYEAn31BodIkzGvJ0axj602Jw/KCY4qq
=oqbL
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#454

Merciadri Luca wrote:

> Lew writes:
>> The finality of parameters is completely unrelated.
  ...
>>> I'm here in the case where each instance of my class defines an object
>>> whose c is the same (->   static), where c is a constant (->   final), and
>>> which does not need to be accessed from other classes (->   private).

[Lew:]
>> What do you mean by "is the same"?  You left out the same as what.
>> What is it the same as?

[Merciadri:]
> Every new ClassName() creates an object so that its c is the
> same. This is normal as there is only one c variable in memory, as it
> is static.

Yes.  If it is 'static final' (keyword order is reversible) then that one 
value is fixed before any class instance can be created.

  ...

> So, is there any reason in the context of my program to declare the
> three ints coming from the CLI (once exactly) as final or not? Their

Well, you're only declaring individual variables 'final' or not.  You can 
assign a value from a 'final' to a non-'final' and vice versa.

In your case, you wonder if the specific method or constructor arguments 
should be 'final'.  That has no influence on anything else done with the data 
from the CLI.  You can corrupt the heck out of data using 'final' variables if 
you like.

> value do not change, and they are only defined once: the user makes
> java myProgram 1 2 3, and then each argument is kept in some
> variable. I consider that this variable should be static, as the user
> is never invited to type any other stuff in the CLI.

No, the variable should not be static.

The decision is not connected to whether the user ever receives any invitations.

The decision is whether it represents state of an instance or the whole class.

In your case, if you have an instance of some class managing the interaction 
with the user, as you should, then the variable receiving the data should be 
neither static nor instance, in other words, not a member at all, but a local 
variable.

If you need to keep the data in something to move it around to helper methods, 
then you encapsulate it in an instance of some class.

That means for that helper class, the data will be kept in instance state. 
Not class state, instance state.  Thus in the helper class, the data should be 
in instance variables.

Most of the time, those should be 'final' instance variables.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#458

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew <noone@lewscanon.com> writes:

> Merciadri Luca wrote:
>
>> Lew writes:
>>> The finality of parameters is completely unrelated.
>  ...
>>>> I'm here in the case where each instance of my class defines an object
>>>> whose c is the same (->   static), where c is a constant (->   final), and
>>>> which does not need to be accessed from other classes (->   private).
>
> [Lew:]
>>> What do you mean by "is the same"?  You left out the same as what.
>>> What is it the same as?
>
> [Merciadri:]
>> Every new ClassName() creates an object so that its c is the
>> same. This is normal as there is only one c variable in memory, as it
>> is static.
>
> Yes.  If it is 'static final' (keyword order is reversible) then that
> one value is fixed before any class instance can be created.
>
>  ...
>
>> So, is there any reason in the context of my program to declare the
>> three ints coming from the CLI (once exactly) as final or not? Their
>
> Well, you're only declaring individual variables 'final' or not.  You
> can assign a value from a 'final' to a non-'final' and vice versa.
>
> In your case, you wonder if the specific method or constructor
> arguments should be 'final'.  That has no influence on anything else
> done with the data from the CLI.  You can corrupt the heck out of data
> using 'final' variables if you like.
>
>> value do not change, and they are only defined once: the user makes
>> java myProgram 1 2 3, and then each argument is kept in some
>> variable. I consider that this variable should be static, as the user
>> is never invited to type any other stuff in the CLI.
>
> No, the variable should not be static.
>
> The decision is not connected to whether the user ever receives any invitations.
>
> The decision is whether it represents state of an instance or the whole class.
>
> In your case, if you have an instance of some class managing the
> interaction with the user, as you should, then the variable receiving
> the data should be neither static nor instance, in other words, not a
> member at all, but a local variable.
>
> If you need to keep the data in something to move it around to helper
> methods, then you encapsulate it in an instance of some class.
>
> That means for that helper class, the data will be kept in instance
> state. Not class state, instance state.  Thus in the helper class, the
> data should be in instance variables.
>
> Most of the time, those should be 'final' instance variables.

Thanks.

- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

Cowards die many times before their deaths; The valiant never taste
  of death but once. (William Shakespeare, Julius Caesar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2TYtYACgkQM0LLzLt8Mhw9awCfUi4ywv96O3S4ITG5xN4wz0LP
YVEAoIXWv7P59InkBkeSrE6GdAadu9/u
=jkj/
-----END PGP SIGNATURE-----

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

#455 — [OT] Re: static final int, but constructor with (final int) arguments

Wed, 30 Mar 2011 00:45:46 +0200, /Merciadri Luca/:
> Lew writes:
>
>> Nope.  Completely not even close.  'c' is static, that means it is
>> attached to the class, not an object.  It can only receive a value
>> once because it's 'final'.  That once MUST happen during class
>> initialization, because it's 'final'.  (That's one of the reasons "I'm
>> sure it won't change" is wrong.)
> As you point it, my interpretation of the final keyword was erroneous.
>> Class initialization completes before you create any instance.  So 'c'
>> already MUST have its value by then.
>> (...)

Merciadri Luca, please use blank lines* to separate your reply from 
the quoted text.  It gets difficult to spot and read your replies 
in-between.  Thanks.

* Something like 
<http://www.oracle.com/technetwork/java/codeconventions-141388.html#487>: 
"Blank lines improve readability...".

-- 
Stanimir

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

#459 — Re: [OT] Re: static final int, but constructor with (final int) arguments

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stanimir Stamenkov <s7an10@netscape.net> writes:

> Wed, 30 Mar 2011 00:45:46 +0200, /Merciadri Luca/:
>> Lew writes:
>>
>>> Nope.  Completely not even close.  'c' is static, that means it is
>>> attached to the class, not an object.  It can only receive a value
>>> once because it's 'final'.  That once MUST happen during class
>>> initialization, because it's 'final'.  (That's one of the reasons "I'm
>>> sure it won't change" is wrong.)
>> As you point it, my interpretation of the final keyword was erroneous.
>>> Class initialization completes before you create any instance.  So 'c'
>>> already MUST have its value by then.
>>> (...)
>
> Merciadri Luca, please use blank lines* to separate your reply from
> the quoted text.  It gets difficult to spot and read your replies
> in-between.  Thanks.
>
> * Something like
> <http://www.oracle.com/technetwork/java/codeconventions-141388.html#487>:
> "Blank lines improve readability...".
>
No problem, Mr. Stamenkov.

- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

Damned if you do, damned if you don't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2TYuYACgkQM0LLzLt8MhyMpACcDgCp0H29haepPZwI9OOfRCTP
H9gAn01GksTrMFoBDmZ6obDEwSJmXXl6
=xYjK
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

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

csiph-web