The Problem
It's too time-consuming and error-prone to keep implementing types like Uniject.Vector3 and Uniject.Quaternion that just mirror types from UnityEngine.dll.
Ripping Types
It may be possible to use System.Reflection and System.Reflection.Emit to steal the implementations of simple structs and enums and put them in a separate DLL that we can reference from our .Core projects without incurring a full reference to UnityEngine.dll.
That way, we can talk about things like vector positions from the game domain (sorry, mixing interests here with Snowball, but it's a relevant use case) without sacrificing the pristine, "You could run your game logic on the command line, no Unity required!" nature of Uniject.
User Impact of Mirrored Types
I'm also wondering if we should somehow prefix or namespace these types, so that we don't burden users with the headache of ambiguous references to Vector3, etc.
The way that we've avoided this for types that aren't direct mirrors has been, for example, IGameObject in Uniject and then UnityGameObject in Uniject.Unity.
The final concern I have with mirrored types, and I'm not sure if we can really do anything about this one, is the awkwardness of mixing the Unity-flavored ones with the Uniject-flavored ones.
An example from the current state of Uniject, note the ToUnity() and ToUniject():
Obj.Transform.Rotation = UnityEngine.Quaternion.Slerp(Obj.Transform.Rotation.ToUnity(),
target, progress).ToUniject();
The Problem
It's too time-consuming and error-prone to keep implementing types like Uniject.Vector3 and Uniject.Quaternion that just mirror types from UnityEngine.dll.
Ripping Types
It may be possible to use System.Reflection and System.Reflection.Emit to steal the implementations of simple structs and enums and put them in a separate DLL that we can reference from our .Core projects without incurring a full reference to UnityEngine.dll.
That way, we can talk about things like vector positions from the game domain (sorry, mixing interests here with Snowball, but it's a relevant use case) without sacrificing the pristine, "You could run your game logic on the command line, no Unity required!" nature of Uniject.
User Impact of Mirrored Types
I'm also wondering if we should somehow prefix or namespace these types, so that we don't burden users with the headache of ambiguous references to Vector3, etc.
The way that we've avoided this for types that aren't direct mirrors has been, for example, IGameObject in Uniject and then UnityGameObject in Uniject.Unity.
The final concern I have with mirrored types, and I'm not sure if we can really do anything about this one, is the awkwardness of mixing the Unity-flavored ones with the Uniject-flavored ones.
An example from the current state of Uniject, note the ToUnity() and ToUniject():