koobas.hobune.stream
Why are Unity functions implicitly virtual
According to this page, all Unity functions are virtual:
All functions are now implicitly virtual, as a result the 'virtual' keyword has been deprecated and the 'final' keyword has been introduced to allow for non virtual methods to be defined as:
I'm curious as to the design goal in doing this. This is obviously the opposite of traditional C# syntax (or js for that matter). I know there is a small overhead to calling virtual functions, but I doubt that played a significant role in the decision to switch this standard.
So my question is simply why make this change, and does anyone actually use the final keyword? Should I be because I would end up putting it on most of my methods?
I think it's ease of use is the main thing they were looking for when they made everything virtual.
You'll notice that on the wikipedia page for virtual functions all of the (in my mind at least) "simple" and "ease of use" languages like java, python, etc. have things as virtual by default while the "controlling", "arcane" languages like C++, C#, etc. force you to define a function as virtual by hand.
Unity seems to want to bring game design to the masses: It's free and it uses simple concepts and a simple scripting system. Throwing the idea of Virtual/Non-virtual at the average joe is the easiest way to scare him off.
Also I come from a java background and I think you're crazy for ever writing a function that you don't want overridden :|
You are probably right, but since we're here, this is an interesting SO thread arguing the opposite.
Well I find myself leaning towards the SO pages argument, but it is what it is.
I still don't see any advantage to the argument in the SO page, in my $$anonymous$$d it honestly feels like a weaker argument than ease of use.
I think it all comes down to the people with C/C++/C#/etc. coding backgrounds like to control EVERYTHING while people from java/python/javascript/etc. backgrounds don't want to control it if they don't have to (you can argue that we're too lazy :P).
C: "Does it work? Yes. Now then, is it perfect? No. I must fix it!"
python: "Does it work? Yes. Now then, where did I hide the Ice cream?"
for UnityScript it made sense to be virtual cause it has not the full set of capabilities to handle the situation as C# does.
Also UnityScript and Boo are "UTs babies" (UnityScript directly and Boo cause its inventor and maintainer happens to be the same guy handling UnityScript and works for UT ;)) and they can go with them where they should go best because they don't have to comply to other standards and more importantly other compilers.
Just cause Virtual is bad on C# with an overhead, the same does not needfully stand correct for UnityScript as nothing forces the compiler to be "stupid" and output it as virtual if no overload is being found for example as it does not have to comply to other standards that would cause that problem.
UnityScript always has been searching for "automagic" as I tend to call it. Don't offer an option to the user he does not needfully require if you can do it all under the hood if we can easily do by inspecting the code and if you ask me it makes sense that UnityScript goes that way as its not targeted at hardcore programmers and professionals which would work with C# for various reasons anyway, UnityScript is there to be easy to those new to unity, new to scripting, coming from web JS scripting or AS3 :)
Look at properties of structs for example which require temp assignements on C# but not on UnityScript and similar things
