-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
const/immutable types #178
Comments
Hey there (:
I see your point. I could see this being a useful feature.
Generally, PyGLM objects are hashable. However, it is dangerous to use mutable objects as dictionary keys: import glm
v = glm.vec3(1, 2, 3)
print( hash( v ) ) # 1443159451135942609
# no problem
k = glm.ivec2(8, 3)
d = { glm.ivec2( k ) : v }
k.y = 9
k_from_d = tuple( d.keys() )[0]
print( k_from_d == k ) # False
print( k_from_d in d ) # True
# (no) problem
k_from_d.y = 9
print( k_from_d == k ) # True
print( k_from_d in d ) # False
# problem
k = glm.ivec2(8, 3)
d = { k : v }
k.y = 9
k_from_d = tuple( d.keys() )[0]
print( k_from_d == k ) # True
print( k_from_d in d ) # False
# problem As for the implementation... I'm more worried about my current type-checker implementation. Due to the way it works, having a two parallel types would be problematic in some cases. Having a I haven't quite made up my mind yet, which option is the best. |
Agreed. My goal is just a best effort at preventing mistakes in the same way that we might return a
Interesting. I guess I just assumed they weren't. Good to know. |
I use pyglm in my toy examples a lot. these are examples for newcommers, beginners, ... class Player:
def update(self):
self.position += self.forward * self.speed
def spawn_footprint(player):
world.add(Footprint(player.position)) the code above spawns flying footprints following the player. Adding an offset to the position or removing it later changes this behavior. Using some I understand the efficiency of inplace operations, the cost of allocating new objects, but I think using it for pyglm causes more harm than help. My point is that, even I can avoid these pitfalls, others may reuse/change the code and find weird hard-to-explain behavior. |
I'd really like to see immutable version of existing vec/mat/quat/array types. Personally, I have 2 use cases for such types:
Immutable objects that contain glm objects
I have objects which are immutable which have pyglm object as attributes. Since pyglm objects are mutable, whenever a user wants to access one of these attributes it requires making a copy of the pyglm object so that the parent object remains publicly immutable. For example:
This isn't the worst thing ever, but I also have cases where I'm doing this with rather large arrays, which is pretty wasteful.
Hashing
I've encountered situations where I'd like to use pyglm objects as dictionary keys and other situations where I've wanted to eliminate duplicates. Since pyglm objects are mutable they can't be hashed, so I've had to resort to converting them back and forth from tuples in many cases.
Immutable versions of pyglm object could be hashable and eliminate these needless conversions.
Implementation
There is some precedent for this already with
array
havingreadonly
. As far as I know it isn't really possible to construct a read only array through the python API though. If all objects had areadonly
attribute that could be set on creation with a keyword only argument that may work?Personally, I'd rather see a whole extra type to avoid the overhead from
readonly
checks. Something like:I think math operations would continue to return the normal objects (so adding two readonly
vec3
would result in a regularvec3
) to keep things simple.Thoughts? I'm happy to work on this if it sounds reasonable.
The text was updated successfully, but these errors were encountered: