0

(for a custom engine) Just a simple question, I was wondering if there was an advantage adding a child this way:

`myNode.transform.parent = newParent` // unity like

instead of this:

`myNode.transform.AddChild(newChild)`

Or is it just a matter of preference.

For my part I find it weird that a setter will do background stuff for example deleting himself from its previous parent children conteiner.

Thanks !

Maxou
  • 23
  • 2
  • 1
    Er...where are you getting `AddChild()` from? This isn't a method listed in the docs - the only instances I've seen it used are as an extension method which just executes your first line... – Serlite Mar 10 '17 at 01:33
  • It is a custom engine in progress inspired from unity that's why you wont find AddChild(). I was just kind of wondering if there was a reason why a node (or gameObject) could set its own parent instead of having an other one adding or detaching its childrend. – Maxou Mar 10 '17 at 01:40

2 Answers2

2

They may be using an AddChild method in the C++ backend to make the addition. Unity's core engine is written in C++, C# is merely the scripting layer that they use. Unity registers their backend methods to front end methods and properties. When somebody uses that property or method, the backend implementation is called instead. This isn't the case for all of Unity's stuff, Unity's UI is predominantly C#, and it's open source to, in case you're curious: https://bitbucket.org/Unity-Technologies/ui/overview.

Here's an article that may clear up some aspects of which would be best to choose, although in practice, it usually comes down to preference: https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx

In general though: methods represent an action, properties represent data.

Another user asked a similar question: Properties vs Methods

Take a peak if my answer doesn't clear it up.

Also, in case you're curious about how Unity calls its backend methods, this may clear it up: https://github.com/mono/mono/tree/master/samples/embed

Hopefully this'll help.

Community
  • 1
  • 1
JJC
  • 246
  • 1
  • 3
  • I suspected Unity's scripting layer to hide me some stuff, since I wont have one I was looking for the most logical approach. Thanks a lot ! I will look to the Properties vs Methods docs you linked. – Maxou Mar 10 '17 at 02:05
0

The other answer is really good but I just wanted to add a little bit of an explanation to why you would use addChild(...) or .parent = ....

It basically comes down to how you build your code, if you do the parent instance then when it is drawing its location, it can just get its parent and then draw it relative to that parent.

Where as if you did the addChild(...) system then the parent has to tell the child where its location is (or you have to have a link anyway to the parent) to draw it relative.

That is just one reason and I'm sure there is plenty, but it does mostly come down to preference.

Braedon Wooding
  • 161
  • 11
  • 1
    I feel you. The inherency system has just started but I like the fact that the node's transform has a pointer on its parent so I guess that the first part you described is better. It is just the fact that .parent =... will have side effects that bothers me, but yeh all that is surely explained in the Properties vs Methods stuff – Maxou Mar 10 '17 at 02:42