Scripting Support #99
Conversation
| // TODO: Re-include the TypeIdHasher as a StorageIdHasher | ||
| storages: UnsafeCell<HashMap<StorageId, Storage /*, BuildHasherDefault<TypeIdHasher>*/>>, |
There was a problem hiding this comment.
Do we need to re-implement our own hash now that we are using StorageId now, or is the default one going to be fine?
There was a problem hiding this comment.
The default one is (and always was) fine. It was a good opportunity to learn about Hash and Hasher but it's probably a good time to remove the custom hasher, it'll simplify things.
There was a problem hiding this comment.
OK, I'll just remove that, then.
zicklag
force-pushed
the
StorageId-migration
branch
from
38e9f89
to
fa04bd0
Compare
|
I think we have to discuss the api before I can merge this PR. Based on the api, if some part can't be used with ffi views, it'll make more sense to use I think a good example of this is systems, they can't work without types. I think ffi systems will do the same thing as workloads. |
|
That makes sense. I've got a plan for a prototype API for scripted systems and components in mind so I'll rename this PR to "Scripting Support" and get those changes up when I have them so we can discuss it. I'm not sure if I'm missing something huge or not, but it looks like it won't be too difficult. So far the code-base has made complete sense to me which is great. I wasn't sure if I would be completely lost if I looked into it. Anyway we'll see how well that goes. 😃 👍 |
|
I'm closing it but I'll take another look inside when I finally try to do scripting 😅 |
Hey there 👋
Here's a PR that attempts to migrate from using
TypeIdto usingStorageIdin an effort to start to address #96.I may have missed a spot here or there, and this doesn't address anything an API change to facilitate creating custom components yet ( necessarily ) it just switches everything I could find that should take a
StorageIdinstead of aTypeId.Definitely needs some review, but all of the tests pass.