Mixedrealitytoolkit-unity: Are these instances of hiding parameters intentional?

Created on 12 Sep 2016 · 9Comments · Source: microsoft/MixedRealityToolkit-Unity

There are various locations where a parameter hides a field or property on the same class or its base. This primarily happens in the spatial mapping section but it is unclear if these are intentional?

For example, in ObjectSurfaceObserver, you have:

 public class ObjectSurfaceObserver : SpatialMappingSource 
{
    [Tooltip("The room model to use when loading meshes in Unity.")]
    public GameObject roomModel;

    public void Load(GameObject roomModel) 
    {
        if (roomModel == null) {
    //more code

ObjectSurfaceObserver
line 31, 49, 65
FileSurfaceObserver
line 42, 58
SpatialMappingManager
line 158, 163, 251, 254
SpatialMappingObserver
line 193, 259
SpatialMappingSource
line 85
PlaneFinding
line 300
RemoveSurfaceVertices
line 217
SurfacePlanes
line 191
ActiveEvent
line 106
SpatialUnderstandingDll
line 275
DirectIndicator
line 84

Source

genereddick

👍1

Most helpful comment

@jwittner,
No, actually that's a great suggestion for getting around the public vs private issue. It still masks the fact that it's a field being exposed on the Editor which may/may-not be updatable via runtime, but should help minimize complaints by style tools. I'll start looking though our code (starting with SpatialMapping) and update as appropriate.
Thanks!
~Angela

angelaHillier on 12 Sep 2016

👍2 😄1

All 9 comments

Yes, most cases are intentional. Ideally, the field would be private, but Unity does not allow private fields or properties to be exposed in the Editor. Because of this, we are unable to follow the design pattern for Properties completely, since we still want to be able to set the initial values for some of the fields in the Editor.

Properties are the preferred approach to get/set fields from another class, and they also save us from having to add a lot of code to the update loop (which could potentially slow your app down).

Are there any particular fields/properties that are causing issues? It might be a little confusing if you're trying to directly access/update a field during runtime. In general, we use the public field for initialization in the Editor, and the Property for run-time updating.

angelaHillier on 12 Sep 2016

No specific issues encountered, just wanted to make sure I wasn't missing something with the conflicts between Unity naming requirements / conventions and usual .NET practices. And so I can tell Resharper to calm down.

Thanks!.

genereddick on 12 Sep 2016

👍1

Thanks @genereddick,
Yeah, our styelcop tool was not very happy about the fields being public either. Alas, until Unity supports exposing Properties in the Editor, we have to break with convention :(

angelaHillier on 12 Sep 2016

Out of curiosity, is there any reason not to use the SerializeField attribute to expose the private fields to the editor?

Docs here:
https://docs.unity3d.com/ScriptReference/SerializeField.html
https://unity3d.com/learn/tutorials/topics/tips/show-private-variables-inspector