ffi.metatype

[raidho36]

So the manual reads as

The association with a metatable is permanent and cannot be changed afterwards. Neither the contents of the metatable nor the contents of an __index table (if any) may be modified afterwards.

But as far as my experimentation goes, you can change contents of the metatable and it still works as expected from regular Lua code, but with FFI ctype data still. Am I missing something here? Is there something different goes under the hood?

[s-ol]

So the manual reads as

The association with a metatable is permanent and cannot be changed afterwards. Neither the contents of the metatable nor the contents of an __index table (if any) may be modified afterwards.

But as far as my experimentation goes, you can change contents of the metatable and it still works as expected from regular Lua code, but with FFI ctype data still. Am I missing something here? Is there something different goes under the hood?

Probably your experimentation results are not guaranteed and depending on the specific usage and optimization happening it might not work as expected.

[raidho36]

Yeah and that's the problem - my LÖVE version allows all of those, but they may not necessarily work on someone else's version and I will never know. It's the same problem as with writing shaders on nVidia GPU machine: it has much more lenient standards about shader code quality and what's considered atrocious by Microsoft, Kronos and AMD's standards and will never get compiled, will easily pass for OK code on nVidia GPU. So you'll never know it had problems until someone else reports them, and even then you'll have no clue how to fix it because you wouldn't know if what you're doing actually fixes anything: it's not broken to you, it couldn't get any less broken than that.

[s-ol]

Yeah and that's the problem - my LÖVE version allows all of those, but they may not necessarily work on someone else's version and I will never know. It's the same problem as with writing shaders on nVidia GPU machine: it has much more lenient standards about shader code quality and what's considered atrocious by Microsoft, Kronos and AMD's standards and will never get compiled, will easily pass for OK code on nVidia GPU. So you'll never know it had problems until someone else reports them, and even then you'll have no clue how to fix it because you wouldn't know if what you're doing actually fixes anything: it's not broken to you, it couldn't get any less broken than that.

Well, that's why that's mentioned in the docs in the first place, so you can stay clear of the bugs right away.
If you write shaders and adhere to a GLSL version standard it should work everywhere, and where it doesn't, it's not your fault.

Also what I meant wasn't even only platform differences, but corner cases that might be required to trigger it. For example, maybe it only happens when a full garbage collection cycle is run inbetween, or only when there are more than 20 instances, or only when there's at least 20 other defined ffi types, ...

it's easy to make these up and it's impossible to prove there isn't a corner case like this that makes it happen on your pc without any insight into what's the actual issue.

And lastly, this is what standardization looks like everywhere. Some companies lag behind the standards, some conpanies stay with the standards, some compsnies try to stay ahead of standards and build incompatibilities with future standards. This is what webdev has been like for two decades.
http://caniuse.com

[raidho36]

Well I restructured the code to never alter the metatable after it's been assigned to a metatype, hopefully this will work properly.