<cite>@pspeed said:</cite> Because you are modifying the fields of an instance and Material does not know that you have done that. You are not changing the reference to a new Vector2f instance.This is fundamental by-value and by-reference stuff.
this is getting out of space time
so
this is not an instance
Float a;
a=a+1
but this is an instance ?
Vector2f a;
a.x=a.x+1
<cite>@pspeed said:</cite> This is pretty antagonistic:Despite the fact that the answer was exactly right.
well , precisely, where do you see the insult ?
this is just childish,
i give up
youre reaction is completely dishonest
I DO USE A INSTANCE AS A VALUE
Iāll use a vec2 instead of a float, and BASTA !
@curtisnewton your attitude really stinks, you need to take a step back and learn exactly what pass-by value means, and also about autoboxing (as it takes a float as an argument). This is Java related and has nothing to do with jME. Then you might understand why changing the value of a float variable outside of the function has no effect. Then you will understand why doing it for your shader does not work, while updating a reference object (Vector2f) does.
Trying to argue with one of the most knowledgeable people here isnāt going to get you very far iām afraid.
@curtisnewton said: well , precisely, where do you see the insult ?this is just childish,
i give up
youre reaction is completely dishonest
I DO USE A INSTANCE AS A VALUE
Iāll use a vec2 instead of a float, and BASTA !
First respond to helpful post, dripping with antagonism. I suggest you lighten up on the attitude and you went full nuclear. I stooped to your level and responded in kindā¦ which is unfortunate.
You have a FUNDAMENTAL MISUNDERSTANDING of Java by-reference and by-value.
Just run the sample code I provided (that used capital F float) and you will see.
Bottom line: setting the fields of an object is different than changing the reference of the object.
<cite>@curtisnewton said:</cite> so you agree that it will keep the instance as it would do with a Vector2F ?
No, I meant quite the opposite of that. And as pspeed pointed out a Float object is immutable, the value of the object cannot be changed, instead the Float is replaced with a new Float with the new value.
This demonstrates Immutability. When I change the value the hashcode changes:
[java]
Float aValue = 10f;
System.out.println( "Hashcode is " + aValue.hashCode() ); // 1092616192 on my run
aValue = 20f;
System.out.println( "Hashcode is " + aValue.hashCode() ); // now changed to 1101104800 ( the instance has changed )
[/java]
As you may know the hashcode is not truly a memory address, ( the object being moved in memory, does not change the hashcode ), but it is a loose expression of the address at object creation time
<cite>@wezrule said:</cite> @curtisnewton you attitude really stinks, you need to take a step back and learn exactly what pass-by value means, and also about autoboxing. This is Java related and has nothing to do with jME. Then you might understand why changing the value of a float variable outside of the function has no effect. Then you will understand why doing it for your shader does not work, while it does for a reference object (Vector2f).Trying to argue with one of the most knowledgeable people here isnāt going to get you very far iām afraid.
i did not mean anything by that
and no matter what you all think , i DO have respect for you guys
i am C++ programmer, and i tend to see java instances as pointers
mea culpa
but at least i got my answer
i just donāt like that people think that i donāt respect them just becos i keep asking while i donāt get it
and ātell me something that i dont knowā is not something usualy meant as an insult
expression can be misunderstood via emails/forum
if we just had this as a vocal conversation , it would have lasted less that 2 seconds, and i would not be considered as an asshole
<cite>@nihal said:</cite> No, I meant quite the opposite of that. And as pspeed pointed out a Float object is immutable, the value of the object cannot be changed, instead the Float is replaced with a new Float with the new value.This demonstrates Immutability. When I change the value the hashcode changes:
[java]
Float aValue = 10f;
System.out.println( "Hashcode is " + aValue.hashCode() ); // 1092616192 on my run
aValue = 20f;
System.out.println( "Hashcode is " + aValue.hashCode() ); // now changed to 1101104800 ( the instance has changed )
[/java]As you may know the hashcode is not truly a memory address, ( the object being moved in memory, does not change the hashcode ), but it is a loose expression of the address at object creation time
i knew about the hash code, but i forgot about the fact that Float were immutable
i had my java training a long time ago
i deeply(honestly) appreciate you explain these simple java stuffs to me
thx a lot mate
no hard feelings
<cite>@pspeed said:</cite> First respond to helpful post, dripping with antagonism. I suggest you lighten up on the attitude and you went full nuclear. I stooped to your level and responded in kind... which is unfortunate.You have a FUNDAMENTAL MISUNDERSTANDING of Java by-reference and by-value.
Just run the sample code I provided (that used capital F float) and you will see.
Bottom line: setting the fields of an object is different than changing the reference of the object.
whatever
definetly your kind of reaction/tastes
did it ever occur to you that you and your judgemental attitude makes otherss write stuffs like ātell me something that i donāt knowā ?
i use some many languages, and apply them in so many fields( including electronics and AI),
but, yetā¦ i guess i am so dumb that Spock would laugh at me, cos i did not know floats were immutableā¦ i am so stupid, shame on me
nihal figured out where was my lack of knowledge while you were just judging/insulting me
pretty sure you feel proud about yourself
@curtisnewton said: nihal figured out where was my lack of knowledge while you were just judging/insulting me
Floatās immutability was not really the issue, though. If that were true and you actually understood what weāve been saying then you would have asked āWhere is the set value method on Float?ā Since there is no operator overloading, it isnāt like there is some = operator magic happening either. For Float to work like Vector2f, youād have to be able to change itās float field. Reassigning the Float reference wonāt help any.
Java is only pass by value. Itās just that some of those values are object referencesā¦ the references are passed by value. So, for example, you canāt reassign the reference in a method either.
C++ has a lot more options for passing argumentsā¦ you actually can pass objects by value (whole thing copied onto the stack) or the object pointer by value. (Or the pointer to the object pointer for that matter.) Java has nothing but pass by value.
<cite>@curtisnewton said:</cite> definetly your kind of reaction/tastesdid it ever occur to you that you and your judgemental attitude makes otherss write stuffs like ātell me something that i donāt knowā ?
i use some many languages, and apply them in so many fields( including electronics and AI),
but, yetā¦ i guess i am so dumb that Spock would laugh at me, cos i did not know floats were immutableā¦ i am so stupid, shame on menihal figured out where was my lack of knowledge while you were just judging/insulting me
pretty sure you feel proud about yourself
The very first reply in this thread was someone telling you exactly what the problem was. Your response was rude and dismissive
<cite>@curtisnewton said:</cite> well, yes , obviously tell me something that i don't know
How is that not rude and dismissive? Especially when he was in fact telling you something you didnāt know! You can hardly blame anyoneās attitude but your own at this point either as this was directed at someone who had written nothing but a helpful reply giving you exactly the solution you needed - itās just your understanding that failed.
@pspeed then repeated the information for you again a different way only to be flat out told that he was wrong and then go into a description of stuff Iām fair certain he already knew, and probably knows better than you do. Now you are rude, condescending and arrogantā¦is that better than rude and dismissive or worse? Consider we are only 3 of your posts into the thread at this pointā¦
An experienced java developer and core developer comes and spends his time to help you and you are rude and condescending. An experienced forum member tries to help you and you are rude and dismissive. A contributor also replies reinforcing what they both said and gets told you wrote an engine years ago.
And then you complain when people call you out on your attitude?
There are ways to project yourself online and make a good impression. Not doing what you did in this thread is somewhere near the top of the listā¦
