And that kids, is why you don't multLocal the static vectors

Coding late at night, this struck me as funny…



http://www.youtube.com/watch?v=UWbxPrUI7AI&feature=youtu.be



I was applying a small impulse to trees inorder to get them to fall when they are cut down… problem was. i was compounding the multiplication on a static Vector from the Vector3f class… so instead of cutting them down, he starts blowing them away…

5 Likes

lol 8)

1 Like

So that’s the difference between mult and multLocal? multLocal stores the result in the Vector3f?

@memonick said:
So that's the difference between mult and multLocal? multLocal stores the result in the Vector3f?

every local dose, using non local methods will create a new vector3f instance.
1 Like

xD

Cool.



They say some of the best discoveries were made by mistake… I reckon the 2nd chop was how you should make 'em all anyway.

haha

:stuck_out_tongue:

Lol I didn’t even knew this was possible. And I use those static vectors a lot, I better check out what I am doing to them.

1 Like

Btw this kids, is the solution to this issue. Its an Annotation processor that can be plugged into the java 6 compiler. It can check how and where variables etc. are passed so it can also pass on any Annotations. So we can annotate these instances as e.g. @ReadOnly and some methods like multLocal as @Destructive and the compiler will warn if one of these methods is called on an object via any reference to it (!) However, its not done and a skeleton only. If anyone feels like it… :slight_smile:

@normen said:
Btw this kids, is the solution to this issue. Its an Annotation processor that can be plugged into the java 6 compiler. It can check how and where variables etc. are passed so it can also pass on any Annotations. So we can annotate these instances as e.g. @ReadOnly and some methods like multLocal as @Destructive and the compiler will warn if one of these methods is called on an object via any reference to it (!) However, its not done and a skeleton only. If anyone feels like it.. :)


And I think that's only done in compiling time, right? Even those instances checks, they only work at compile time?

Because you could also create a Vector3fStatic that extends the Vector3f, and override all Local operations to call the correspondent non-Local methods. What do you think about that?
@shirkit said:
Because you could also create a Vector3fStatic that extends the Vector3f, and override all Local operations to call the correspondent non-Local methods. What do you think about that?


You'd have to make Vector3f non-final... which would slow down every other access to Vector3f... just to fix a relatively easy to avoid programming mistake.

Oh, and you'd have to rearchitect Vector3f to hide its fields... which would slow down every other vector access even more.
@pspeed said:
You'd have to make Vector3f non-final... which would slow down every other access to Vector3f... just to fix a relatively easy to avoid programming mistake.

Oh, and you'd have to rearchitect Vector3f to hide its fields... which would slow down every other vector access even more.


You think the suggestion said by @normen is good? I didn't like it in the beginning, but the other alternatives involves complex things, but I'm going with the Keep it simple idea nowadays.

I think making vector3f non-final is bad. Whether compile time annotations are good or bad is more a matter of preference… even those can be “worked around” in strange ways if a developer really wants to mess something up.



Programmers can do all kinds of bad things and writing good programs takes a certain amount of experience. I’d really hate a framework that attempted to keep me from doing anything bad because a) it would make the framework totally crappy and b) it wouldn’t work. There is always some way to subvert and even remotely useful API.



The safest way to program is to leave the machine turned off, after all. Performance is constant and no new bugs will ever crop up. :wink:

@shirkit said:
And I think that's only done in compiling time, right? Even those instances checks, they only work at compile time?

Because you could also create a Vector3fStatic that extends the Vector3f, and override all Local operations to call the correspondent non-Local methods. What do you think about that?

Whats the issue with compile time? Its about finding these mistakes. Your solution would also not fail before compile time. And most IDE's compile all the time, thats where the cute red lines come from. The latter solution is not good, it bloats jme with like 10 new classes just to find a bug thats easily avoided, we had this discussion before.

So the best solution should be to leave as it is. At maximum, a common error FAQ could be created, but I don’t even think that’s this case.

How about reading the Javadoc?



If you see two methods that look very similar, javadoc is your best answer. It’s clearly stated what “local” usage do.



Nevermind. Nothing to see here. Move along.

1 Like
@madjack said:
How about reading the Javadoc?

If you see two methods that look very similar, javadoc is your best answer. It's clearly stated what "local" usage do.


Reading javadoc?!? That's crazy talk. Next thing you'll tell them is that if it's still confusing they can right click on the method and view the source.

This will all lead to nothing but trouble as budding developers learn to find the easy answers themselves and the forum becomes a cold and lonely place, filled with only hard-to-answer questions.

:) :) :)
1 Like

Haha, spot on @pspeed :stuck_out_tongue:

@pspeed said:
Reading javadoc?!? That's crazy talk. Next thing you'll tell them is that if it's still confusing they can right click on the method and view the source.

This will all lead to nothing but trouble as budding developers learn to find the easy answers themselves and the forum becomes a cold and lonely place, filled with only hard-to-answer questions.

:) :) :)


We can't have that. I'll rewrite my post.
1 Like