Skip to content
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

Allow prototype references to be actual references #196

Merged
merged 1 commit into from Jun 18, 2022

Conversation

steamroller-airmash
Copy link
Owner

This commit is a rather big design change in how prototypes are written and used. Before this, references to other prototypes were just strings. If you wanted to get the prototype that it was referring to it was necessary to go and look it up in the hashmaps contained within GameConfig. This was doable, if inconvenient.

It would be much more convenient if, instead of going through strings and hashmaps, we could just directly access the corresponding prototype to do this. This commit makes it so this approach works.

The way it does this is like so:

  • Prototypes are parameterized by a type implementing the trait PrototypeRef. This is a sealed trait which provides a few associated types which are the types of each individual prototype reference.
  • There are two concrete implementors of PrototypeRef: StringRef and PtrRef. These set the prototype references to be strings and actual references, respectively.
  • Finally, when we convert between GamePrototype and GameConfig the string references are converted into real references and the whole thing is leaked so they all have a static lifetime.

The disadvantages of this approach is that the types are rather messy and that it leaks memory every time a GameConfig instance is constructed. However, the amount of memory is rather small and GameConfig should only be constructed about once for each execution of the program, so I think this downside is worth it.

In addition, GameConfig has an unsafe method to reclaim the leaked memory and actually free it. Usually there's no point in using this but it might be needed if we want to track down other memory leaks in the program.

This commit is a rather big design change in how prototypes are written
and used. Before this, references to other prototypes were just strings.
If you wanted to get the prototype that it was referring to it was
necessary to go and look it up in the hashmaps contained within
GameConfig. This was doable, if inconvenient.

It would be much more convenient if, instead of going through strings
and hashmaps, we could just directly access the corresponding prototype
to do this. This commit makes it so this approach works.

The way it does this is like so:
- Prototypes are parameterized by a type implementing the trait
  PrototypeRef. This is a sealed trait which provides a few associated
  types which are the types of each individual prototype reference.
- There are two concrete implementors of PrototypeRef: StringRef and
  PtrRef. These set the prototype references to be strings and actual
  references, respectively.
- Finally, when we convert between GamePrototype and GameConfig the
  string references are converted into real references and the whole
  thing is leaked so they all have a static lifetime.

The disadvantages of this approach is that the types are rather messy
and that it leaks memory every time a GameConfig instance is
constructed. However, the amount of memory is rather small and
GameConfig should only be constructed about once for each execution of
the program, so I think this downside is worth it.

In addition, GameConfig has an unsafe method to reclaim the leaked
memory and actually free it. Usually there's no point in using this but
it might be needed if we want to track down other memory leaks in the
program.
@steamroller-airmash steamroller-airmash enabled auto-merge (squash) June 18, 2022 01:51
@steamroller-airmash steamroller-airmash merged commit 88009de into master Jun 18, 2022
@steamroller-airmash steamroller-airmash deleted the multifunctional-prototypes branch June 18, 2022 01:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant