Use stringifiers to eliminate the need for duplicate "real" and "reference" properties

[ekolis]

What needs to be cleaned up?

If I can make a stringifier that takes a mod object or referrable and prints its ID when serializing (and looks up the ID when deserializing)...

How will this benefit us?

...then we won't need all those silly duplicate properties on various objects, the real object properties and the reference properties! That will clean up a lot of code!

Plus the savegames will get a bit smaller without all those silly ID properties that are the only property of the references being serialized...

Heck, we might not even need the reference classes, since the only reason they exist is to support serialization...

What potential drawbacks are there to making this change?

We have to deal with lots of different types of objects. I don't think stringifiers can be generic types. So unless there's a way to handle all mod objects and all referrables using the same two stringifiers, this might not be possible.

Plus there are a LOT of properties...

[ekolis]

I wonder if the new C# generic attributes will let stringifiers handle generic types?

[ekolis]

Wait, aren't there times we do want to store a real object, like a design when it's being created?

[ekolis]

I suppose those could be marked with a special attribute. That would also prevent unexpected objects from being inserted into the game state!

[ekolis]

As it turns out, I was able to do this using GameReference and ModReference attributes hooked into the serializer rather than stringifiers.

These changes will be included with the changes for #272.

[ekolis]

Actually, this didn't quite work out; there is a need for a two step deserialization process where first all the objects are instantiated, and then they are all linked together via references. I haven't been able to get that working without the reference properties yet.

[ekolis]

Perhaps it's time to create some proper view models, rather than just using the models themselves for that purpose. That way the models could contain the IDs only and the view models could contain other view models. But view models are supposed to be linked to a specific view as well as a specific model, aren't they? That would lead to a lot of duplicate view models...

[ekolis]

#292 is the view model issue

[ekolis]

View models are linked to a specific view. They're not necessarily linked to a specific model; a view model could contain data from zero, one, or many models.

[ekolis]

Really the reference properties should go in a data model, and then the actual properties would go in the domain model, and computed properties would go in the domain model and/or the view model depending on where they're needed. Separating ou the reference properties into the data models would enforce the two step loading process.

[ekolis]

data models #312