Inheritance? or something else?

Unity Engine
, , ,
41

I may have to bow out of the discussion as it seems to me that no real headway is being made. It sounds like you have all sorts of logical reasons for wanting stuff to be a certain way but I’m asking you to take a moment and question why people here with (I will guess) more experience are questioning your conclusions.

I could definitely be wrong but the odds that I am wrong (in this case) and that your design is the one that makes sense is quite small. That isn’t some sort of boast but you may think that it is. You decided to try ineffective alternatives to get rid of errors. Again using the car analogy, you decided that mixing corn oil with the gasoline “might help”. So what’s your next guess?

Read/analyze your post when you have a moment. You’re are explaining mathematically how many effects, armors and stuff your solution will have and how you’ve engineered things to work so well as if none of us has done the same (or more) without the problems you are having. It makes no logical sense except that you feel you have a handle on development that we simply do not have. Or perhaps that your project is unique in its complexity and requires special non-standard ways of doing common, every day things. Understand (if you can) that we all compute stuff.

Good luck on your game. Think about that fact that I (and others here) could have written it by now without any compiler warnings. You are mistaken about how OOP languages work and (it seems) the ideal way to compartmentalize data and behaviors.

We tried :slight_smile:

42

Ohh I got it now. C# creates “hidden” fields when you create { get; set; } properties like that but I didn’t know Unity would serialize them too, but I guess it does. So my bad for suggesting that haha. Putting the NonSerialized attribute on them like spiney199 suggested should hopefully fix the errors this time.

43

Yes, this is a little detail is a bit hidden, but they actually updated the documentation and mentioning it in several places.

  • Note: In some cases private fields are serialized, refer to Hot reloading

Unity serializes properties with auto-generated fields during hot reloading only.

If you don’t want Unity to serialize a property with auto-generated fields, use the [field: NonSerialized] attribute.

Since the hidden backing field is not visible, when you want to apply attributes to those backing fields, you have to use [field: XXX] on the property to apply it to the backing field.

It would prevent the serialization error, yes. But it’s still the wrong approach. Your class instance would have those fields duplicated!!!. Just because they aren’t accessible anymore does not mean they do no longer exist. Fields defined in the base class will ALWAYS carry over to any derived class since a derived class IS also a base class. Redeclaring a field in the derived class will ADD this field to the class. Since both fields are private, they can only be access from within their own class scope. That’s why it’s possible to have two or even more variables with the same name in the same class.

public class A
{
    private int myVar;
}

public class B : A
{
    private int myVar;
}

public class C : B
{
    private int myVar;
}

An instance of class C will have 3 int fields, all named “myVar”. However du to the access modifiers within the scope of C, only the one declared in C will be accessible. The other variables may still be accessed through methods defined in B or A.

So don’t declare an auto property in a base class and override it again with an auto property. This would duplicate the backing field.

If such a value should be hardcoded and never be changed anyways, the base class can declare a virtual read only property and the derived class can override the property. Though this makes no sense for reference type properties.

public class A
{
    public virtual int myVal => 0;
}

public class B : A
{
    public override int myVal => 42;
}

Here the class does not have ANY fields at all. It’s an empty class. “myVal” is just a property getter (a method) that returns a constant value. The derived class simply overrides that method with a new one that returns a different constant. Though as I said, reference types can not be constants. So it would not make sense for reference types as the method would need to create / recreate that array each time you read the property since there’s literally no memory in the class to store it anywhere.

2 Likes
44

Interesting, thanks for the explanations!

45

I quickly made a C# fiddle to show the actual effects of actively hiding derived fields. When the fields are protected, you generally can access them from derived classes. However when “hiding” them with new ( which is necessary when using protected or public) they are also still there but access would be limited. With base you can access the immediate base field, but when it was already hidden, you can’t reach the one defined in the first class. Though in the end our class C still has all 3 fields. I added properties to access the individual fields to show they are still there and with actual code in the right scope you can work with those values.

1 Like
46

omg, Bunny83, abstraction. jesus, the things one can forget. you are my hero.