Hey everyone!

I found it super awesome that people here are really supportive to new game developers. I have a small question about creating new Contain methods for data structures other than primitive data types. I'll try my best to explain what I mean, I've created a Scriptable Object called Item that I want to add to my game. The new method I wanted to incorporate was ContainsItem to check if my inventory contains a specific Item. 

I was hoping to call ContainsItem to an array of Items, Item[], but it gives me this error.

How do I resolve an issue like this? Thanks in advanced!

Hello! Glad that helped you a little!

I'm adding a few links with this post so you can learn properly, but yeah, you were trying to achieve with private fields and manually implemented functions what can be done with properties.

A field is a way to store a variable like so:

public float TestFloat;
private string testString;

Its values can be read or changed. Private fields can only be accessed in the same class, and public fields can be accessed outside the class. Something you already used in your code.

But properties are an interesting thing. You can control what's going out or in with them. You can even alter the result or play with it. 

Now an example:

public float MyValue;
public float HalfMyValue { get { return MyValue/2; } } 

In this example I have a public field and a public property. The property 'HalfMyValue' does not allow to change any value (no setter), but it will give you always half the value of the MyValue field.

Properties are actually a full structure of a backing field and get and set functions. So beware, they are not the same as a field. And in some way, they are considered syntactic sugar (not a bad thing, they make easier/faster to write code).

Auto-properties, or autoimplemented properties have this look:

public float MyValue { get; set; }

And they are a contracted way (write less) to make this:

private string myValue;
public string MyValue{ get { return myValue; } set { myValue = value; } }

These two offer the same functionality as a public field (public and no limitations or changes to the value).

The thing is, that Unity inspectors do not work with auto-properties. A lot of people already requested the feature... but... well... not there yet. 

I'm adding now proper reading about this, surely they can explain the subject a lot better than me:

https://stackoverflow.com/questions/295104/what-is-the-difference-between-a-fiel...

https://www.jeremymorgan.com/blog/programming/properties-vs-fields/

https://forum.unity.com/threads/c-use-of-auto-properties-in-unity.200114/

https://stackoverflow.com/questions/1180860/public-fields-versus-automatic-prope...

https://softwareengineering.stackexchange.com/questions/161303/is-it-bad-practic...

The fight now is when is or what is correct to use, one or the other, because in the professional development world... public fields are a no-no, they are bad practice and you should stick with public properties instead, but yeah... then we have Unity Editor and its inspectors, where we need those public fields if we want to access them when designing a game.

I've a lot of frustration about this (and I still have) because of my experience on business software development, but hopefully, this video will ease your mind:

Best of lucks!!