search

jamiebrynes7 / spatialos-sdk-rs

Rust integration of the SpatialOS C API bindings
Apache License 2.0
21 stars 6 forks source link

Allow users to opt out of generated code, component database, etc. #83

Open jamiebrynes7 opened 5 years ago

jamiebrynes7 commented 5 years ago

A feature that has repeatedly come up in PR reviews and discussions has been allowing users to replace the default generated code or opt out entirely and pass in raw Schema objects.

Currently, the implementation assumes that you are using generated code of a specific shape and structure. (i.e. - using the Component trait, using inventory for auto-registration).

We should allow and support for this level of granularity and let users opt in at whichever level they want. From high level to low level:

  1. Use default generated code and associated traits, types, etc.
  2. Custom generated code, but still using the associated traits, types, etc.
  3. Opt out of generated code and associated traits, types, etc. entirely.

Using cargo feature flags may be an appropriate way of handling this - but some decisions will need to be made around which direction these feature flags go (i.e. - default is the low level, and you opt into higher level features or default is high level, and you opt out of the high level features).

This will likely be a big chunk of work to isolate out these parts of the codebase and can likely be done post v0.1.0 release

randomPoison commented 5 years ago

What's the use case for opting out of the SDK-provided traits for serialization? I get disabling vtable serialization so that they can control when serialization happens, but what value would there be in opting out of the traits entirely?

There's also the question of how this interacts with code generation in dependencies with regards to #56.

jamiebrynes7 commented 4 years ago

Important to note that vtables will be gone as of #146. Custom generated code is still on the table though :)