Type is not an object?

So i was reading my programming book and i came across this paragraph and i feel like i need to understand moving forward so can anyone explain to me what the author is trying to say? Thanks for taking your time to read this.

A Type Is Not an Object
Type, as we’ve mentioned, is the name given to a class of an object. Like a vowel, or noun, type refers to the classification of a thing, not the actual thing itself. Semantics is important when dealing with programming, and it’s very easy to miss the meanings behind how words are used. For instance, if we need to tell a function the type of a class, we can’t simply use the class’s name.
GetComponent(Player);
If the function expected the type player and not the object player, you’d get an error. There’s a subtle difference here. The type of an object is not the object. However, it’s difficult to say “this is the type Child” and not the “Child” class object. The two things use the same word, so it’s easy to confuse.
There is a function that will get the type of an object and satisfy functions that need types and not objects. And that’s where typeof(Child) comes in. If we have the object Child typeof(Child), we can put Child into the typeof() function and use that function as the type of Child and not the class Child.
Give the FindObjectsOfType() function a typeof(Child) and it returns an array with every instance of Child in the scene. We can give the Example.cs a GameObject ChildObject; to chase after. Just so we don’t get confused what version of the word Player we’re looking for we should make it tremendously clear what we’re looking for.

GetComponent<Player>();

?

I think it is because he is trying to show an example or its just outdated.

OK… saying class is a bit restrictive, since not all types in C# are classes.

You have:
Class
Struct
Interface
Enum
Delegate
Array

So I might have a Player class, a Vector2 struct, a IPlayer interface, a PlayMode enum, a System.Action delegate, or an int array.

All of these are classified as ‘types’. Your objects are of some type (or multiple types, through inheritance, implementation, etc). When you refer to the ‘type’ of an object, you’re not referring to a single object, but the categorization of the object.

Of course, there is a object that you can use to programmatically represent the type of an object. This is useful for what is called ‘reflection’. This type is the System.Type class:
https://msdn.microsoft.com/en-us/library/system.type(v=vs.110).aspx

You can get the type object of a type by saying ‘typeof(type you want)’. For example:

var tp = typeof(Player);

You can also get the type of an object by calling gettype on the object:

var pl = GetComponent<Player>();
var tp = pl.GetType();

Sometimes this ‘type’ object is useful. For example there is a version of the GetComponent method that accepts System.Type instead of the generics.

var pl = GetComponent(typeof(Player));

So what is the difference between GetComponent(); and GetComponent(typeof(Player));

i am guessing GetComponent(); gets the object and GetComponent(typeof(Player)); gets the type and you can also get the type by doing GetComponent().GetType(); and i don’t quite understand your definition of type.

there’s no difference in what comes out. They both get the component of type Player.

One determines what type of component to get based on generics (the method)

The determines what type of component to get based on the System.Type.

Burn the book. That’s probably the most convoluted description I’ve ever read, and if you keep reading it you’ll be back every five minutes with questions. Even the terminology is not correct, the word instance should be used heavily in this paragraph. It should also mention the convention of naming types versus instances. For learning C# check out the yellow book. For learning Unity check out the tutorials in the learn section.

Care to name the book so I can recommend people avoid it?

Type: This refers to what a class, struct, enum ect actually is. Common types you will use in Unity include GameObject, Vector3, Transform ect. You can also define your own types, like PlayerController, Weapon ect. Convention is to use PascalCase to name the types.

Instance: To actually use a type you need to create an instance of the type. An instance refers to the actual location in memory where the data exists. Every instance can have different values for each variable. Convention is to use camelCase to refer to instances.

Examples: In unity GameObject refers to the type. gameObject refers to an instance. Transform is the type, transform refers to an instance.

You can find the type of an instance using GetType. GetType(gameObject) is the same as GameObject. If you have the type and want to find an instance attached to a specific game object you can use GetComponent.

2 Likes

Thanks i know what a type actually means now and i think the book is really good so i have no intentions of ruining its reputation i am just getting ahead of myself that is all. I am pretty sure the author knows what he is doing and this is the only time i stopped to ask a question relating to the book. since the book has not gotten to introducing other types the author limited himself to using classes as an example and the word “instance” does not have to be used depending on the version of explanation you are using but i do appreciate it. Another thing is i do not know where he gets object from if you do not mind to elaborate on his convoluted explanations. You also mentioned If you have the type and want to find an instance attached to a specific game object you can use GetComponent, but GetComponent takes in types.

GetComponent certainly does take a type as an argument. But it returns an instance.

What’s the name and author?

Ok thanks.

So if you think the book is good, why not share it so others can benefit from the book? I can then read a bigger excerpt from the book and make a better judgment.

At this stage I question your ability to evaluate the subject matter correctly. Books should be written by experts on the subject matter. And expertise needs to be judged by other experts.

Ultimately a book should stand on its own, and not need to be elaborated on to be understood. I’m not overly keen to elaborate on this guys work when there are better resources out there for you to learn from.

You have to understand not the whole book will make since to people it is this one part that i did not understand and i really love the writing style if he came out and explained this through details like you all do that will throw me off alot more anyways the book is titled Learning C# programming with Unity3D by Alex Okita.

This book?

https://books.google.com/books?id=GJLNBQAAQBAJ&printsec=frontcover&dq=Learning C# programming with Unity3D by Alex Okita&hl=en&sa=X&ei=yu1PVZXeKsuwsAWZxYDYCg&ved=0CDIQ6AEwAA#v=onepage&q=Learning C# programming with Unity3D by Alex Okita&f=false

I’m not a fan of the writing style… but that’s opinion I guess… not that I could do any better, I’m not a writer. I’m a programmer.

I just don’t like how he jumps from concept to concept mid paragraph in trying to explain something, and avoids labeling that stuff or using standard terms for it. Like he mid paragraph while explaining that classes are blueprints, he starts discussing encapsulation and why its important. But he never uses the word encapsulation, nor explains how encapsulation is done in code. Then 3 paragraphs later, he’s back on talking about classes as blueprints (which is object identity). Personally I think using a standard glossary of names is beneficial so that way you can 1) communicate the concepts to other people already well versed in the area of knowledge, and 2) you can cross research those concepts from other sources.

2 Likes

Yeah, my opinion of the source material hasn’t changed from reading the excerpts on Google. I already know how to program, and struggled to follow some of his passages. It might work for some, but based on a cursory read through I couldn’t recommend it.

On further reading some of the information is just straight up wrong.

The topic jumping is pretty annoying. Half a page listed as “Value and reference types” talks about bits as 1s and 0s.

Yeah, needless to say I won’t be buying this book.

1 Like

This is nonsense. The only reason it won’t make sense is if it is poorly written. These days I try to go with books recommended by StackOverflow, StackExchange, and have good reviews on Amazon. Thanks to this policy none of my current books have sections I cannot understand in full.

You have to understand that someone new to a subject cannot make a good estimation of a book’s value. Trust me when I say I’ve been there before with such a book. I had a book titled The Complete Idiot’s Guide to C++. At the time I was learning I thought it was a sound book, but looking back at it years later I realized that not only was it badly written but it wasn’t even following the standards that had existed prior to the book’s published date.

It worked with a single compiler that was already way out of date and any other compiler would have refused to compile the code it had in it. Many books that I’ve owned in the past that reached the point where I wasn’t able to learn any new excerpts (typically beginner books) get sent to rummage stores, but this particular book went to recycling.

2 Likes