Unity3d not using true Javascript?

The same reason that Netscape called the language "JavaScript" even though it bears only the vaguest similarity to Java. Marketing, and trying to cache in on an established brand.

 

The best I can think of is Marketing. Prior to 3.0 in their info pages they advertised the fastest JavaScript in existence. And while both Boo and C# leverage existing knowledge bases, they probably wanted a parallel to a third language for their own. No-one is going to be more excited to use Unity upon hearing it supports it's own proprietary language syntax.

 

Didn't read the entire thread, but Unity also doesn't use the true C# too!! ^_^...

 

You can't qualify a programming language by their age/how long they existed. Basic, Pascal (the really old one, not Delphi), COBOL are old, but it doesn't mean they are still viable for programming (and yes I know they are still used in some per-historic software/organizations).

Java (not JavaScript) is also older than C# and even platform independent etc. But it's not a very good language in terms of usability has some big design flaws. Microsoft on the other side has addressed some of the issues of Java and avoided doing these in C#, which is one reason why many people prefer C#. It's modern, it's well designed and it's good organized and doesn't have many of the flaws of existing languages.

The only real flaw with .NET (not C# in particular) is that it's bound to Windows and is imho the only reason which prevents from making Java completely obsolete. While mono offers some alternative, it always lags behind major .NET Framework updates and do not implement all of it's features.

using xxx only imports namespaces. GUILayout is no Namespace, but a class, so it doesn't work. C# (same as Java) have all of their classes organized into namespaces. Basically all classes which logically belongs together get in their own namespace.

i.e. all IO operations/classes/enums/types can be found in System.IO.*, everything related to compressions, if you want to access the Serial Port System.IO.Ports is the right namespace for it.

Java C# have one thing in common: they are purely OOP. While C++ had some OOP extensions, C# Java implement it fully. One of the advantages was of course of allowing Classes having same names but different namespaces.

If you work with Forms and want to add a button. If you're developing for windows, you add this to your C# file:
using System.Windows.Forms;
and could instantiate an button

Button myButton = new Button(....);

If you're working in ASP.NET, you use
using System.Web.UI.WebControls;

instead. The class is still named Button. In C++ it was common to name Classes like: WinButton and WebButton etc. to avoid class name conflicts.

As for your problem stated above, well... there are Class Extensions which allows you to add static members to an existing class (which will be threated like an instance method), but would in your case require to use the "this.Button(....)".

edit:
You could of course make a class derived from MonoBehaviour, implement the GUI.xxx methods in it to act as wrappers and then derive all your C# scripts from MyMonoBehaviour instead of MonoBehaviour, but I don't think that's what you was asking for.

But this would not require to use this.xxx like the extension method from above.


However, extensions can be used for other neat features like this one

Code (csharp):

1.  
2. static public class ZIPTools {
3.  
4.     public static bool IsZIPCode(this string zip) {
5.          // validate if the string is a valid ZIP code here
6.          return true;
7.     }
8. }
9. ...
10.  
11. string zipCode = "12345";
12. if(zipCode.IsZIPCode()) {
13.    Debug.Log("ZIP code is valid");
14. }
15.  
16. // instead of
17.  
18. string zipCode = "12345";
19. if(ZIPTools.IsZIPCode(zipCode)) {
20.    Debug.Log("ZIP code is valid");
21. }
22.  

That's basically how basic Linq functionally was added to default types/classes.

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using System.Collections.Generic;
5. using System.Linq; // Important for the extension methods
6.  
7. public class Score {
8.    public int score;
9.    public int name;
10. }
11.  
12. public List<Score> scores;
13. ...
14.  
15. // sort scores alphabetically (ascending)
16. scores.OrderBy(score => score.name);
17. // sort scores alphabetically (descending)
18. scores.OrderByDescending(score => score.name);
19.  
20. // sort by score
21. score.OrderBy(score => score.score);
22.  
23. // sort by hash (doesn't make sense, just for example)
24. score.OrderBy(score => score.score, (a, b) => {
25.     a.GetHashCode().CompareTo(b.GetHashCode());
26. });
27.  
28.  

While it may looks bit more complicated at the beginning, once you get the Lambdas, LINQ etc. it makes some things much easier, like sorting. I don't know how many lines of code you'd have to write without lambdas, delegates or linq, which can be done in 2 lines with them. And since .NET 4.0 you there is even support to parallelize linq expressions.

But that's some advanced C# techniques. People new to C# probably wouldn't start with them before they get a good knowledge of the basics of C# and OOP programming in general (not tied to a certain language).

 

...groan - Unity doesn't use true C#...next you'll be telling me it doesn't use true Unity Script.

I look forward to my book...

 

Well, it does use C# in its 3.5 or 4.0 language features as of Mono 2.6 which is currently used in Unity3D. That's stuff like lambdas, delegates, syntax, extensions etc.

What it do not fully support is the complete .NET Framework API. For example, the System.Windows.

There is a .NET <-> Mono Compatibility List (it's for Mono 2.8, Unity uses Mono 2.6):

http://www.mono-project.com/Compatibility


EntityFrameworks - Not available.
Server-side OData - Depends on Entity Framework.

WCF - silverlight 2.0 subset completed
WPF - no plans to implement
WF - Will implement WF 4 instead on future versions of Mono.

System.Management - does not map to Linux
System.EnterpriseServices - deprecated

That's basically the namespaces which are either not implemented yet, only partly or are not where no plans exist to port them (WPF = Windows Presentation Foundation, XML based UI).

But basically, 80% of the .NET Framework API should also work on mono too, if you don't depend too much on GUI and Windows specific features.

 

Maybe you should... because that's plain wrong.

 

Look, if you drew a pie chart of the users who use C#, UnityScript, and Boo, the pie would be all C#, and there would be tiny slivers for the other two. If you want to use the other two, go for it. It's just going to be easier to use C#, because there are so many resources for it, and so much help everywhere. Literally millions of webpages and users. Seriously. But do whatever you want and makes you feel happy - it's not like your choice is going to change our lives. Just yours.

 

I think my last complaint with C# was the Round function :

- http://forum.unity3d.com/threads/114713-Round-vs-RoundToInt

Of course I am not expert C#, but really.. that is a pretty basic function X_X....

Anyway... always a way to find a way to do what we want to be done!

 

I read your question, but don't understand it. If you want to use Math.Round, just use it instead of Mathf.round:

double f = System.Math.Round (1.2345, 2);

 

This comment won't relate to anything, (I got a bit bored after the second page), I learnt scripting via diving headfirst into the FPS tutorial back around the start of 2.0, I had no idea about any languages but I spent a long time looking through all the code and trying to figure out what each one does. I leaned towards US purely because it was naturally going from those first tutorials to the API, which by default is in US. Right now, I can easily read C# and interpret it into US.

Right now the only reason I'd change to C# is if there was a magical simple function within to save a game state, rather than using the hideous player prefs (Trying to understand that has been like a brick to the face, arrow to a knee).

 

Well I must admit I skipped a few posts, forgive me for any repetitions.I believe I've became relatively efficient in both JS and C# in the last year and I found my learning to be very easy and I believe it has to do with the language(s) I used - or perhaps I just want to share my 2 cents.

LONG VERSION:
I had done a little web programming a few years ago so I decided to go with JS. Most official Unity references and ressources tend to favor JS - possibly to propose an easy learning curve. Now if you're new to programming, you'll be busy for a while with only movements, inputs, guis and so on. Not serialization, generics, the Photon API or even the common System namespaces.

Are you not hitting any problems the Unity API can't resolve? Good, then just for practise start adding the #pragma strict directive to all scripts. Fix all new errors.

Unless it happened already - Unity let you down and you find no class or methods to do anything close to what you need. The time has come to head over to the MSDN library, what you need IS there. It just is, somewhere, somehow.

Found it? Now on top of the page it says Framework 4.0 - C#. Flip that to 3.5 as Unity's Mono implementation is currently at 3.5 anyway and the Syntax menu now sometimes(rarely) offer you JScript examples. I've found them to be usable as-is within Unity ... 100%? of the time.

When examples are missing, you have to copy the C# example into a new JS script and translate it yourself. Having used the #pragma strict already make sure you're familiar with Types already. Soon, you'll have translated enough C# to write some yourself, but you won't need to...

...Until you find an awesome tool or framework that requires you to work with C# and then you hit the hell-sent compilation order problem. Then you're running into all kind of trouble to get scripts from both languages to talk to each other and the only true solution is to have all scripts using the first-compiled language, and that is C#. By that time, you'll be good enough to make your own choice. I've recently moved over to C# to solve that last problem and I must admit I'm starting to really love using C# with Visual Studio...

TLDR:
I advocate the 5 steps method:

1. Learn and use JS.
2. Add the #pragma strict directive.
3. Translate C# to JS when you need to.
4. Use C# by necessity sooner or later.
5. Use C# to avoid compilation problem hassle.

 

Like this one?

http://support.microsoft.com/kb/815813

 

Sort of, although I'm new to the concept of serialization. Are you saying you could place a value as say:

Code (csharp):

1.  
2.  
3.  
4. clsObjects p= new clsObjects();
5. p.Pos = // all game objects with a tag of "object"?
6.  
7. // save transforms, statuses or something?
8.  

Forgive me as I don't really have a clue, but what I've been looking for is state saves, similar to anything found in emulators that can somehow save a game exactly as that point in time, the entire scene, and load it back up again - I wouldn't care about size.

 

No, that won't help for that. You're talking about saving the contents of a virtual machine and restoring it. That would work if unity were a virtual machine, but it's not.

Serialization just dumps objects to a string/file/whatever in a format that makes it easy to load back up. For Example, you would create a "GameState" class, and put all the stuff you want in it, and then serialize the class. (and then deserialize it to load it). It works recursively also, so you can store collections of objects, and they can store objects, etc. It does all the grunt work, but you still need to supply it the data.

 

So what if I wanted to store the transforms of every object in a scene, what information would I give?

 

You would create a class to hold them, and then create a List<> to hold the transforms in that class. You would also need a way to associate that transform with an object.

This is kinda derailing the thread, but since you live in Australia (my daughter just moved there), I'll type something up tomorrow and pm it to you.

 

Huh? Are you really saying that just because i don`t learn it in your way and order i am not able to learn it at all? But i already have, with my way and order

Learn it when you need it is my approach. It`s an approach that works perfect for me since several years. And doesn`t mean that i don`t jump outside of Unity to learn the missing steps when i get stuck. Why should i learn about pathfinding before i need it? Maybe i don`t even need pathfinding in my game project. But yeah, i`ve learned pathfinding then. Great. The only difference to your approach is that you learn everything before you need it. And that way you learn stuff that you willl never ever need too. Which is wasted time and energy. I would say my method is a bit faster and more efficient therefore. Of course it is more focussed at the current goal.

Unity is made to make your life easier. Unity was especially made to cut away the need for the traditional route, to study a language for two or three semesters before you are even able to make a simple Pong clone. My goal is to make a game, nothing else. I simply see no reason why i should go that old traditional route then

 

Sadly that's not true. UnityScript by far has a greater percentage, than you may assume. 2/3 of the Android Market games I found were done mainly in UnityScript.

So it's quite widely used, which is sad as C# has just greater toolset and possibilities, less problems etc.

I'm not sure what your problem was over there. Documentation clearly states that Mathf.Round and Mathf.RoundToInt both methods round to the next integer.

Documentation clearly states that Mathf.Round(...) is equivalent to Math.Round(..., 0); in .NET Framework.

So if you want to round to 2 decimals, just use Math.Round(..., x) (the Mono/.NET implementation of Round).

However, Math.Round in Mono/.NET only takes returns decimals () and doubles, so if you use them you have to cast back to float

Code (csharp):

1.  
2. float percent = 23.239f;
3. percent = (float)Math.Round(percent, 2);
4.  

since most values used in Unity (i.e. Vectors etc) are floats. If you want to complain, complain to Unity why they only implemented round to integers.

Which is absolutely the wrong from an professional point of view.

That's the reason why we have so many incompetent people here in Germany. Like all that great admins I've seen in the companies I've been in who are incompetent enough to do the simplest security measures to the companies servers. Like running the company webpage on an 6 year old machine Linux SuSE (horrible OS, horribly outdated hardware) without backup and an OS which hasn't been updated in 5 years. No Security updates, no OS updates, nothing.

And then wonder when their servers got hacked. I've seen everything. Same for programming. People who think they are programmers cause they did 3 scripts in PHP with horrible organized and unreadable code... iirrks.

 

Since Boo is basically C# with Python syntax, it has the same "toolset and possibilities" as C#, requires much less typing, produces more readable code, etc, so why aren't you using that?

I'm guessing because you prefer C#. Nothing wrong with that, just like there is nothing wrong with the programmers that prefer Unity Script.

 

But I'm discussing the number of users of each language in general, not just how many users making android games in Unity. C# is used by far more people, so much that US and BOO don't compare. "Millions" is what I'm told by MS, and I believe it, because there are over 1000 just at my company.

 

Heh, so everybody is incompetent that doesn`t share your opinion and doesn`t follow your holy path?

Forgive me my clear words, but you are talking bullshit here. The way how to learn says absolutely nothing about the quality of what you have learned. And it says absolutely nothing about how you use the learnt stuff then.

It may be your personal opinion that your way to learn is the only valid and correct way to learn ever. That everything else is heretic. And that the whole world is made of morons but you. But i am the proof that you are wrong. I make games since years, and have always sucessfully finished what i have started. I have a webserver running too, and you can believe me that it is a secure one, and up to date. You simply talk nonsense here, sorry.

 

Well, no Boo is not basically C# with Python syntax. Boo is a python-syntax language developed for Microsoft CLR (but also wirks with Mono, since both basically compile to IL Code). Don't mess up the language with the Framework (.NET or Mono), that's two completely different things. UnityScript, C# and Boo (VB.NET, IronRuby and IronPython) all compile to the same CLI/IL, they all utilize some or all of the Classes available in .NET/Mono.

But the huge difference is: C# was specifically made for the Microsoft CLI, hence it supports ALL of the CLI features, which other languages don't.

For example the new async/await keywords introduced in C# 5.0. It makes it very easy to implement async tasks and have a clean and readable code. The compiler does the complicated stuff in the background. This async/await keywords are pure language specific semantics.

As for Boo/Python: I don't like the syntax, is very hard to read. Ruby/Python are languages made to minimize the amount of code without keeping it really readable. I actually tried ruby, when I was in need for a HTML scrapper which I could run on my server, but it's syntax is just horrible. Worse than JavaScript, worse than Java, worse than Delphi/Pascal. Almost as worse as Basic.

That's not actually what I said. I said everyone who believes he could start straight with programming a game without basic knowledge of programming is going to fail.

And what I wrote above is from experience, and that being said, I'm not even the best programmer. I'd rank myself somewhere around "good", a 6-7 on a scale of 10 (10 excellent, 1 worst). But half the people I've met in the past 10 years, are far worse than that... and they had "higher position" in that company, which is just hilarious. You know, we call it "Armutszeugnis".

They just write ugly code, they don't know proper OOP, they made code which is a hell to maintain or read and they have absolutely no idea about application design. The guy who was following me, after I quit at my last company (cause I was fed of their incompetence to get anything done properly), was supposed to have "Years of experience in PHP, HTML and JavaScript and worked on many web based applications before", so my last "task" was to introduce them in the projects I did before i quit...

And I can tell you, that guy was absolutely incapable of understanding the OOP concept. All he ever knew was some ugly, procedural PHP and JavaScript code and working with ugly hacks. After a month he was unable to do even little changes to ExtJS (which is pretty OOP oriented, if you make a WebApplication purely in ExtJS). That's the sad truth in German companies, just no one wants to admits it.

And that's actually the kind of people who "just start making it" without firstly proper learning the concepts of programming. The stuff they produce may or may not work "good enough", but it's ugly, can't be extended very well or at some point only scrapping and starting from sketch would help. The admin in the same company also didn't had a clue about it. Why was it my job to tell him a horribly long list of all the security flaws of the companies servers, when he gets paid for it and it's not even my primary job.

That's why I neither support this kind of people or approach of learning something, it just leads to horrible results for the whole industry and drags down (in this case the programmers) profession into the dirt. The last thing the world needs is more wanna-be programmers, who can barely write more than a few very simple scripts. One of the reasons why Germany became when it comes to products or services (like software) in the past 10-15 years. 20 Years ago "Made in Germany" was a seal of quality, today it just marks bad/mediocre products.

 

It is according to the Boo developer. Who just happened to create UnityScript, btw.

Beauty is in the eye of the beholder. I find C# to be one of the ugliest, unreadable languages I've ever had the misfortunate of using. But again, that's one of the great things about Unity, we have a choice of languages. Choose the one you like, just don't belittle the people who make a different choice than you.

That's true (unless they start with pong), but...

There is nothing wrong with procedural programming, too many young programmers are a bit too married to the whole OOP paradigm. It's a tool, and can be a very convenient tool for game development, but it isn't a necessary requirement for programming. Most of the great games from the 80's weren't using object orientated programming.

 

And i say the opposite because of my years of experience. I am the living proof that your thesis is simply wrong. Because i did and do since years the for you impossible. And i finish my games. That easy.

You have to start somewhere with learning. And you have to start small. That`s the key, the only key that really matters. Not a special language or a special way of learning. And when you start small then you can also directly start in Unity. With UnityScript. Straight, with programming a game without basic knowledge. You will learn this basic knowledge with the smallest possible projects on your way. There is absolutely no need to learn C# outside Unity. There is also absolutely no need to learn C# at all when you want to make a game in Unity. There is also no need to learn OOP outside Unity, Unity is object oriented by design.

Maybe you should widen your mind a bit and simply accept that there is never just one working way

 

Interesting. Any sources on this?

OOP makes many things easier. .NET/Mono is purely done in OOP. It's very hard to do stuff that's not OOP without some horrible hacks, as there are no globals in it.

Yea sure... you obviously never throw a look at some of the Scripting requests here or on Unity Answers. While I love it to help others with some specific problems (If I know a solution or whatever), there is in incredible amount of absolute noob questions which are related to basic programming knowledge.

I'm sorry if this sounds a bit harsh, but this is Unity forum/Answers site for Unity related problems, it's not there to teach people the most basic things about programmings. Too many too noobish questions just spam away the Questions/Help request of people who really have a problem to do something in Untiy and don't fail on the basics of programming.

Whenever I got time and nothing important to do, I browse through Unity Answers or here on the Forums, as it brings two major advantages:
1. You see interesting problems and interesting solutions, hence you learn from questions and problems other had. This may save you from having searching a solution or asking yourself in future if you encounter a similar problem
2. If you already solved that problem and someone else asked or it's something you can explain and is unity specific, you can help the other and they may in return start to helping others too.

But whenever I see complete newbs posting some snippets of code they copy and pasted from some source (may it be other Answers, Forum posts or unifycommunity wiki) without understanding neither the basics nor the snippet of code thy just copy and pasted and want others to write their code, I can't help myself but to either enrage or ignore that post/answer.

This is the very exact reason why I tell EVERYONE who doesn't know the most basics of programming, to first start with it. If they don't get this, their future with Unity Development looks everything but bright.

Over and out.

 

I think we can actually all agree on this. With the exception that using UnityScript or C# as 0 bearing on this. You can start small, and start directly with Unity using any of the 3 languages. The arguement I'm trying to make, and some others as well, is that by choosing US over C# you are forfeiting the ability to look outside Unity for resources. It's true you don't have to, but all you are doing is closing doors. You are more likely to succeed with more resources. Having less resources doesn't add any benefit. Both languages at the base level have the same features(though at an advanced level US is missing things).

You can use US and learn to program but the main thing you are doing is using a language with less support, less documentation, less users (therefore less help). And is therefore less. That doesn't mean unacceptable, it just means less. So I suggest to people who are starting out to use the choice with the most available resources and tutorials and documentation, because all it will do is increase their likelihood of coming out the other end a programmer.

Edit:Actually that entire post you could swap JS and C# and it's still exactly the same and equally correct. You don't need to know JS to make a game in Unity either.

 

One of the main advantages of C#, I believe, is the possibility to use Visual Studio. Here are several lines of code written in MonoDevelop:



Looks normal until you start to actually read or compile it. And here is how it looks in Visual Studio:



VS just won't let you write such a crap, you'll see it immediately, and it will help you to save much time later.

 

If I was to teach a class of 15 year olds some basic code, I'd teach 'em using unity and US script.

But in an environment where I can't assume the person in question has proper guidance/mentor-ship C# is stricter, which means that there are entire categories of bugs that would be greatly or significantly reduced. Simple things like proper typing of variables is more explicit in C# [especially the resources available], and I'd feel they'd waste less time.

Just rambling here.

 

Isn`t that where every learning begins? At the absolute noob questions? I can`t really see what`s wrong with it

There is a misunderstanding. Nobody stops you to look for other resources outside Unity when there is need to. I´m just against the traditional approach, to learn stuff that you will never ever need.

Like? Do you have an example what can be done in Unity with C# and not be done with Unityscript? That would be a bug then. Because the thee languages in Unity have to provide the same functionality.

 

Can US work with events?

What about the C# ref and out keywords?

 

Neither does exist (no events handler usage, no ref and no out - ref normally is handled automatically where the unity api offers it like onserializenetworkview for example), nor has UnityScript linq or multicast delegates

 

Here's what I've got so far.
Anonymous delegates, or use LINQ, or use Events, or +=/-= delegate syntax(they are multicast, but the assignation is annoying), or (at least didn't work in 3.0) assign a char via single quotes, as well as Ref/Out. Or use a fully fledged IDE (Visual Studio/MonoDevelop) with Intellisense/DocFood/Code Completion.

 

But there are no external UnityScript based resources. And even things you need can be more easily learned outside of Unity, like proper serialization and reflection tutorials. Or Delegates/Events, which make many systems immensely easier, have no JS resources (not to mention don't even work). Unity does not provide a from scratch to pro training, and being able to use what Unity provides AND other resources is better than only being able to use what Unity provides.

Not everything outside of Unity tutorials is never needed or not incredibly useful game development knowledge.

 

Nope. If you're serious into programming you reading books or some of the 100.000s of Tutorials about that language, which explain the basics. Then you try it yourself and if you stuck with some of the more advanced things you ask.

Just not here, but in (in this case) C# specific Forums or on sites like http://stackoverflow.com/. Great site, great resource. Once you understand the basics and try out unity and have a UNITY specific problems, it's pretty valid to ask HERE. However, it's not task of the people around here to teach you the most basics of programming as this is not a "learn programming" site or answers (for unity answers), it's specific to Unity itself.

Additional to that what the other two posted:

Extension Methods (I already posted an example one or two pages back)
http://msdn.microsoft.com/en-us/library/bb383977.aspx
http://en.wikipedia.org/wiki/Extension_method

One thing many haven't mentioned: Properties. Properties are very useful for many kind of things, especially related to OOP.

Code (csharp):

1.  
2. public class MyClass {
3.     private int score;
4.     public int Score { get; set; } // 1. Default getter  setters
5.     public int Score { get; protected set; } // 2. Default getter  setter. Setter can only be access from derived classes
6.     public int Score {
7.         get {
8.             return score;
9.         }
10.         set {
11.             if(value <= maxScore) {
12.                score = value;
13.             }
14.         }
15.     } // 3. Both, getter and setter are publicly available, but setter has a validation. But in code you threat them like a variable, ie Score+=10, Score++ etc.
16.     public int Score {
17.         get {
18.             return score;
19.         }
20.         protected set {
21.             if(value <= maxScore) {
22.                score = value;
23.             }
24.         }
25.     } // 4. Same as above, with the difference, that it's read-only when accessed from outside, but is read-write from within the class and it's derived classes
26.  
27.     ...
28.     // somehwere insde of your class code
29.     Score += 10; // 1. adds 10 to the score
30.                         // 2. works to inside the same class
31.                         // 3. works too
32.                         // 4. works too
33. }
34. ...
35. // code outside of your class
36. myClass.Score += 10;   // 1. works
37. myClass.Score += 10;   // 2. fails, because setter is protected
38. myClass.Score += 10;   // 3. works
39. myClass.Score += 10;   // 4. fails because setter is protected
40.  
41.  

Advantage of all of th is is, you can handle the property. Without properties and with getter setters you code looks like this:

myClass.SetScore(myClass.GetScore()+10);
instead of
myClass.Score += 10;

Which is cleaner and more readable?

Edit:
Disclaimer: Most of this C# specific language features are indeed NOT suited for complete newbies. That's one of the reasons why you need a basic understanding of C# first, before you can learn this more advanced techniques before you can utilize them.
For a complete beginner they may indeed look very cryptic and hard to understand, which is the reason why they first need to learn C# properly before starting developing in Unity3D C#. But the basics in C# are quite easy and can mostly be applied to other languages too (polymorphism, protection levels, member variables, classes structs, generics, for/while loops etc.).

But for programmers who are proficient with this advanced language features, it's a powerful tool for clean, flexible and productive code.

 

Properties do actually work, however the syntax is undocumented. I saw it on the forums once, but it was apparently similar to ActionScript properties.

Although when undocumented by the language creators it might as well not exist.
Same with the Multicast delegates. +=, -= doesn't work, but System.Delegate.Combine() can get a sort of +=, -= working, but it's much less friendly.

Overall,neither of these are things a learner is going to figure out anyway.

 

What about

Code (csharp):

1.  
2. lock(someObject) {
3.   // Do code which isn't allowed to be accessed by multiple threads at the same time?
4. }
5.  

I'm not sure if that's a very good idea to use in C# Unity, as don't know if that may or may not cause problems with Unity3Ds multi-threading while it renders the game. Haven't seen an reference to that in UnityScript.

Or about

Code (csharp):

1.  
2.     using (FileStream fsSource = new FileStream(pathSource, FileMode.Open, FileAccess.Read)) {
3.         // do some read/write operations on that file
4.     } // the filestream resources will automatically be released, once the code execution leaves this block
5.  

?

 

lock I'm pretty confident not (and mutlithreading in Unity is quite beneficial still; You can use a lot of multithreading for non-Unity API work like building meshes or loading files, and then just assign the mesh/data to Unity objects back on the main thread, using a job queue or other system).

However using depends on if JS has try-catch-finally.

using is just some compiler trickery.

Code (csharp):

1.  
2. using(FileStream fs = new FileStream(...))
3. {
4. //DoStuff
5. }
6. //DoneStuff
7.  

Just gets converted to this at compile time

Code (csharp):

1.  
2. FileStream fs;
3. try
4. {
5. fs = new FileStream(...)
6. //DoStuff
7. }
8. finally
9. {
10. if(fs != null)
11. {
12. fs.Dispose();
13. }
14. }
15. //DoneStuff
16.  

But I've not seen finally used in JS, so I'm unsure if it exists.

 

Also:
Unity script doesn't have Params.
http://msdn.microsoft.com/en-us/library/w5zay9db(v=vs.71).aspx
Workaroundable, but trying to make a million proper overloads or corral stuff into arrays yourself is messy and less intuitive.

 

I know that the compiler converts that at compile time, same for async/await, Properties, delegates, lambda etc.

But using(...) statement is a C# language feature which has nothing to do with the underlying code it gets compiled to. The hole point of language features is to have it easier (like not having to call Dispose and write a try/catch/finally and improve readability. Of course, you can also use getter and setter methods in C# and not use Properties at all, but that quite of misses the point of having a language like C# which was specifically made to be easy to use with the Microsoft IL code and supports many features or make the code readable, where other languages fail.

After all, its a UnityScript language feature discussion not about the underlying IL Code

 

Fair enough, I can agree with that, especially when one of the listed benefits of US by it's users is less code, more readability.
I'm just making sure we don't have someone come in and go 'Oh yeah, you can do ALL of this' and give the translated code (i.e. anonymous delegates become static functions, properties get their function equivalents, etc...).

Though I'm always surprised that every time this is asked I find a fair bit more to add to the list of stuff you can't do easily in US.

 

Properties exist in UnityScript too, they are just craptastically documented as the whole language and for C# users likely 'unintuitive'

 

I still disagree, and i am still the living proof that you are wrong. Your told way is ONE way, not THE way

That`s the part i can live with.

 

As a person who prefers C# I have to add one point that I actually do NOT like about Unity's C# integration : Getters / Setters are great for code encapsulation and validation, but a get/set variable does not appear in the inspector even if it is public. If you want a get/set variable to appear in the inspector window you have to write a custom editor script for your class, and that's just a pain. In an ideal world, the editor would show get/set properties just the same as it shows unadorned public variables

 

Well, you can actually, with Attributes.

Code (csharp):

1.  
2.  
3. public class Example : MonoBehaviour {
4.     [SerializeField]
5.     private int privateField;
6.  
7.     public int MyProperty {
8.         get { return privateField; }
9.         set {
10.             if( /* sanity check here */ ) {
11.                privateField = value;
12.             }
13.         }
14.     }
15. }
16.  

Even though this kind of "beats the purpose" of properties/encapsulation, because there is a chance that you enter invalid values inside of the inspector. However, that's better than having a public field, where there are much more places in your code where that variable could get assigned invalid values.

 

That's pretty sweet. I still like the idea of bounds-checking though, which really is only possible from within either an editor script or using some sort methods where OnDrawGizmos tries to do a self-assignment like this.MyProperty = this.MyProperty in order to trigger the bounds check.

that feels dirty though. I need a shower just looking at it.

 

I do agree with Tiles. After 2 years on Unity I could not tell why to use C# and not US. The learning path in Unity is much more closer to master its API, engine, workflow than about language. OOP and programming skills help a lot yes but that is a different matter and are not related with language choice.

 

I've been doing some javascript and jquery stuff for a client. Learning web dev turned out to be quite fun with the technologies available today.

Anyhow, to get to the point. I've enjoyed this 8 part series by Douglas Crockford (of "The Yahoo" as he calls it). http://www.youtube.com/watch?v=JxAXlJEmNMg and his book javascript the good parts

He basically discards a few bits and concentrates on other bits showing javascript to be a beautiful OOP language.

Now, I'm wondering is UnityScript - ecmascript 5 compliant? Does it implement Protoype? (function.prototype // object.protoype)?

I'll head out and check myself later this afternoon/evening.

 

Unityscript is not at all ECMAScript. It doesn't do Prototype (thank goodness).

--Eric

 

Well, it turns out that Javascript is a prototypal language so I guess Unityscript is far from being Javascript.

I'm actually falling for prototypalism

Though it has my brain in a small knot.