Improbable Icon


Using Schema Objects as Models



Dear all,

I would like to gather some feedback from both people Improbable and from community members how much merit the following architectural hypothesis has.

In Elrakis I use many different Units due to its size and during procedural generation I record the results in components. An example is the Radius of a Celestial Object, which is expressed in kilometers instead of units. I do this because it decouples the entity data from the implementation (my unit is currently set at 1 AU) and to make zooming / scaling easier.

Currently I use a model that I wrote myself in code but the schema also generates objects for me. Thus far I have used primitives directly in my schema but I am wondering whether it would actually be better to merge my off-schema model and use Value Objects in my schema that I give extra functionality using Extension Methods.

So here is a simplified example; first the old schema definition:

package elrakis;

import "elrakis/types/units.schema";

component Planet {
  id = 2002;
  float radius = 3; // Radius in KM

then the new Schema definition:

package elrakis;

import "elrakis/types/units.schema";

component Planet {
  id = 2002;
  Kilometer radius = 3;

The new definition would allow me to have one Value Object named Kilometer that is generated by SpatialOS (instead of 2) and to make the schema more expressive because you can now directly see the unit involved.

Another intended benefit is that using Extension Methods I could inject an implicit conversion method in the Kilometer value object that would be able to convert it into an AU (for example).

Would there be a benefit or downside to such an approach in your opinion?


Nobody has feedback on this concept? Ahhh :slight_smile:


Hi Mike,

I think it’s a neat idea. It would certainly help when reading through code and could easily prevent certain mistakes.

The only downside I can see is that there will be a slight overhead for the extra wrapping that needs to happen. I think it will incur a two-byte penalty for the extra wrapping - rather than just a float, you have an inner Kilometer type with a single float inside.
It really depends on your application as to whether this extra overhead is significant or not. If the value doesn’t ever change, then an extra two bytes when the entity is checked out on a worker should be insignificant.

So yeah, I think it’s a nice idea that certainly makes some things clearer for very little overhead.