How about introducing read only interface for vectors, quaternions?

Currently, I’m studying Ardor3d and jME3 and both are very impressive.

Especially, jME3 gets stronger day by day. Wow!



But jME3 lack of read-only inferface for basic data structures such as Vector3f, Quaternion

it is good practice to eliminate mistakes.(It is same as ReadOnly- interface in Ardor3D)

How do you think about this?

I think we rather count on assertion checks than limiting the engine too much. In fact, in jME3 its not as easily possible as in jme2 or ardor to falsely swap location vector objects etc.

Cheers,

Normen

I’m glad to hear it is difficult to accidently modify vector objects.

I wonder how but maybe I have to investigate more.

Thank you for the answer. :slight_smile:

As far as I understand, jme3 also has the same vulnerablilty as jme2.

We can get translation, rotation instance reference by getLocalTranslation(), getLocalRotation(), etc.

And even Vector3f.UNIT_X elements can be changed.

This cannot be checked by assertion or any other ways.

I don’t think introducing read-only interface limits engine’s capability.

It rather strengthen the stability of the engine.



Actually, I know it needs changes for a lot of code, and it is not appropriate for current release of engine.

I just hope that it will be done some other day.

getLocalTranslation().set() wont move the spatial, so the user will probably notice pretty fast that it wont work and do it correctly. I still regard this a rather drastic control mechanism.

If I understand rightly, getLocalTranslation().set() will be reflected after the call of setTransformRefresh().

Then it is very difficult to find the bug, because it is asynchronous.



Maybe it is meaningless change, I think it is very good practice.

According to the code getting larger, it’s difficult to track this kind of trivial mistake.

it may be based on just the naive programmer’s mistake.

But if it is prevented by grammar, we don’t need to worry about that.

Anyway, thank you for listening my humble opinion. :slight_smile:

I’ll end up the discussion here.

Well i think it would be easier to just hit all coders doing that stuff with a

Java for c++ coders book until they understand they can program elegant here ^^

We could at the very least gather a proper list of common "do-not"s?

that would be agood idea

If someone can provide me with a proper “do not” as a result of this discussion, I can get started on the page :slight_smile:

Do-nots, yeah, love that idea, start the page! One do not is calling updateGeometricState() on a spatial (see wiki entry “updategeometricstate”), another is trying to move a spatial with getLocalTranslation().set(Vector3f); Then… overriding updateGeometricState(), also forbidden. Trying to use getWorldLocation() after using setLocalTranslation(), forbidden… Uh… start the page and I will add :slight_smile:

Me too.

https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:do-nots

In my humble opinion, but nobody will ever read a “do-nots” page and if they read it, nobody will remember more then 1% of the “do-nots”.



I like Jme3 a lot, and such a “do-nots” page will just be a cover for a bad API design. There will be decisions to make in the API but if you can just append the “do-nots”-list ad infin um you never will do the Right Thing.



Today you start with getLocalTranslation().set(Vector3f) and in 2 years you have 100 entries in the list.

Well I dont think so. This list is more to check back if your thoughts are in line with the structure of the api. Its about common misunderstandings and also for people coming from jme2. Also I cannot agree that its “bad api design” not to check for every possible mistake the user makes. A simple fact in jme2 was that you could share a Vector3f among multiple objects by using setLocalTranslation(Vector3f) and although it lead to problems, it was an interesting option or “featurebug” for people who knew how to use it.



Cheers,

Normen

I suggest that Vector/Quaternion classes implement read-only interface, but do not change engine at all.

Then user who want to use it can setup an abstraction layer.

Currently, user can’t do anything because they are final class.

that might be an idea, or something similar

But in generall I think there is far to much stuff you can do wrong to take into account,

Also you can’t really blame the api design for it, as the main reason for the way the api is still the opengl relictinterface

Thank you for the reply.

But I don’t understand what you say. What you mean ‘opengl interface’?

Today I found that even LWJGL Vector3f implements ReadableVector3f interface.

As it seems, Momoko_Fan is also fond of the idea of a readonly version of the math primitives so you might see this kind of protection soon in jme3. I still dread it :wink:

Cheers,

Normen

I’m certain that when you use it, you’ll like it.

LWJGL introduces read-only interface. Ardor3D has one.

Swing doesn’t use read-only interface but it creates a new instance when getXXX() is called.

I experienced and I know there is a reason for that.

My own tweak version of jme2 has read-only interface and it never limits engine’s ability at all and makes my life easier and happier.



And again and always. Thank you for the all attention.