I come from C# so I’m having a hard time with JS sometimes…
How do I define a property that would go like this in C#:
public string SomeString
{
get { return someString; }
set { someString = value; }
}
Or alternatively, is there a way to declare a var that would be publicly accessible from other scripts, but couldn’t be set in the editor?[/code]
I’m no JavaScript genius, but why not just do this:
function SetSomeString( value )
{
someString = value;
}
function GetSomeString()
{
return someString;
}
Or, better yet, just use C# 
function get SomeString() { return someString; }
function set SomeString(s) { someString = s; }
I believe that works. The best JavaScript docs that I know of (that are close to how Unity JavaScript works), are located here:
http://developer.mozilla.org/es4/spec/spec.html
Nope, tried it already, doesn’t work.
Back when I was into webdev I drove myself crazy for days with this property getter/setter thing, to my knowledge only Firefox supports this (probably Opera too), IE doesn’t.
And of course JScript.NET supports it too, and I thought that Unity’s Javascript was JScript.NET, since it’s Mono/C#/Boo and all, but apparently it’s not the case. I still don’t get what Javascript implementation Unity’s using, or even WHY use javascript and .NET side by side… hell, why use .NET at all on a Mac environment??
But I guess that’s off-topic… hey, don’t get me wrong, Unity rocks, we tried a bunch of engines and didn’t decide lightly that it was the best, but man do I find these choices weird.
OTEE created their own JS implementation.
Some obvious reasons I can think of for using Mono, is speed, cross-platform ability (Windows, and room to grow to Linux), a plethora of languages to choose from to use as scripting languages. Granted, I don’t like JS very much, it’s an easy enough of language for inexperienced programmers and artists to get into 
I’m sure their are quite a bit more though!
Our JS implementation is builtin ontop of .NET. It’s a custom compiler we wrote ourselves (Rodrigo Oliveira has been working on it)
The reason for using mono is primarily speed (As in running 20x faster than Mozilla based JavaScript) and the ability to interoperate with multiple languages and having an abundance of utility libraries available to people. I could keep on going with the list of advantages but those are the most important.
The reason for building our own JS, by creating a compiler that generates .NET dll’s, is because we felt that performance was extremely important. I would hate to explain to people that using C# resulted in better performance than JavaScript.
So instead we wrote our own, which uses concepts like type inference and has very similar performance to C# and is roughly 20x faster than Mozilla based JavaScript. As far as i know it’s the fastest JavaScript implementation in existance.
Just out of curiosity, since you guys took the trouble to rewrite a JS implementation, why didn’t OTEE decide to create their own “UnityScript”?
Just curios
OK, thanks everyone for the info.
So basically, no properties in JS, uh? Is that something we can expect for Unity 2.0?
So I guess that means that the other way around, C# isn’t slower, right? Or any other MSIL-language, like Boo? If that’s the case, why not use JScript.NET, or is it proprietary to Microsoft?
Sorry about all these ramblings, but I’m still undecided as to whether I should use C#, which I prefer, or JS, which the community seems to be using more: when in Rome, do as the Romans…
C# was my big favorite while coding for the web, but in a game environment where everything is much more dynamic and reflection is everywhere, I have to admit that JS and its type inference is a blast.
On a related subject, I think it’s really a pity that while using .NET, you don’t respect their upper/lower-case conventions, ie a variable is lower-case and a function upper, while in .NET the distinction is usually made on private/public.
I have no preference one way or the other, it’s just a convention, but having both mixed-up makes Unity code heterogeneous.
And the “Unity framework” isn’t even consistent between JS and C#:
JS:
var s : String;
C#:
public string s;
… String, string, what’s up with that?? C# in VS certainly accepts both!
So I guess you started with JS, then included .NET, but do you plan to homogenize this in 2.0, or later? I realize backward compatibility would take a hit, but I really think it would be better in the long run.
OK, I’m rambling again… I just like my code tidy!
whether I should use C#, which I prefer, or JS
makes zero difference. use c#. cheers!
If I were you, I’d use C#. Using JS type inference can be slow.
The thing with the strings you pointed out isn’t OTEE’s fault.
“String” is a .NET type (so you can do var myString: String = " "; in JS and String myString = " "; in C#. The ‘string’ type your seeing in C# is an alias for ‘String’. Check out http://msdn2.microsoft.com/en-us/library/362314fe(VS.71).aspx for proof 
Good advice, I’ll take it into consideration. It’s certainly less frustrating to write more code if you know it’s worth it !
Well, exactly, string is an alias for String (same with int/Int32, bool/Boolean), so why does it throw a compile error when you use the “real” type instead of the alias?
Try this:
using UnityEngine;
using System.Collections;
public class NewBehaviourScript : MonoBehaviour {
string s;
String S; // doesn't compile
}
I get the following:
The type or namespace name 'String' could not be found.
Add
using System;
… of course!!
I was so used to VS always putting in on top of all classes…
Actually it’s not, and anyway it only happens at compile time. Dynamic typing can be slow (which is something quite different from type inference), but just put “#pragma strict” at the top of your script if you want to make sure it never happens. Use whatever you like, of course, but I’d recommend JS because the type inference, among other things, makes writing code less annoying (and, again, makes no speed difference whatsoever). I’ve found there are some areas where you have to go through some contortions in C#. You can’t do this, for example:
transform.position.x += .5;
Instead you have to do this:
Vector3 pos = transform.position;
pos.x += .5f;
transform.position = pos;
I prefer “just doing stuff” rather than having to fight with the code like that.
–Eric
Hmmm, I thought type inference was the same as Dynamic typing.
So, what is type inference?
Type inference is this:
var someString = "Blah";
This is inferred at compile time to be a string, and it has no performance penalty. Using “#pragma strict” will have no effect, since it’s statically typed. It’s exactly the same thing as this:
var someString : String = "Blah;"
This is why I prefer type inference…of course it’s a darn string and it’s completely obvious, why should I have to specify that when the compiler can figure it out? Usually the only time I really specify types is with floats/ints, just to be absolutely clear.
(Since you can run into trouble if you mix those up. For example, “var someNum = .5;” is inferred to be a float, but if I later change that to “var someNum = 1;” instead of “var someNum = 1.0”, then it’s inferred to be an int, and that might screw up the code. So to play it safe I’d write “var someNum : float = 1.0;” in case I get forgetful or lazy and write an integer there later when I really need it to be a float.)
Dynamic typing is this:
function OnCollisionEnter(collision : Collision) {
if (collision.collider.name == "Blah") {//whatever}
}
Using “#pragma strict” will cause this to not compile since it’s figuring out the type on the fly every time the function is called. Instead you’d do this:
#pragma strict
function OnCollisionEnter(collision : Collision) {
var col : Collider = collision.collider;
if (col.name == "Blah") {//whatever}
}
So it does take an extra step to statically type this, in this case. But in my scripts, anyway, I’ve found that dynamic typing isn’t common at all, and if it’s being done in a function that’s called rarely, it’s not really worth the bother of fixing it.
Here’s another example of dynamic typing:
var script = GetComponent(MyScript);
script.SomeFunction();
Since it has to figure out the type on the fly. In this case you can make it statically typed just by changing it to:
var script : MyScript = GetComponent(MyScript);
script.SomeFunction();
–Eric
not surprisingly, i had no idea about this ; )
if you don’t mind elaborating a bit, any function like the first example (with an argument) is dynamically typed? and for these functions that are called alot this will help with performance?
Well, no, in that example it’s only “collision.collider.name” that’s dynamically typed, since it’s having to figure the type Collider on the fly. The variable “collision” of type Collision (yeah, possibly confusing naming there ) is statically typed.
If I were to do
function OnCollisionEnter(collision : Collision) {
if (collision.rigidbody) {//Whatever}
}
for example, there’s no dynamic typing there, since I’ve already specified the type Collision and there are no other types involved.
Yep. For something that’s called only once in a while and it’s dynamically typed, but that makes the code simpler, then who really cares if it takes some nanoseconds longer to execute? If you have something computationally intensive, though, then it makes sense to ensure it’s statically typed. Thus I tend to put “#pragma strict” at the top of any scripts that use functions that are called every frame, or for heavy setup code that I want to run as fast as possible. This will catch any instances of dynamic typing that I might have overlooked. (To me, anyway, it’s not always immediately obvious.)
–Eric
Hmm, I don’t see how if (collision.collider.name == “Blah”) is dynamic at all. collision.collider.name type should be known at the runtime (the compiler).
Unless this type inference is specific to OTEE’s implementation, I’ve always known this var someString = “Blah”; to be dynamic typing.
It’s not quite that simple, but it doesn’t really matter anyway; just put “#pragma strict” in all scripts if you never want to deal with dynamic typing.
Yep, it is! They’ve talked about this in various topics before. It’s one of the cool features.
Yeah, that’s just with “normal” Javascript and does not apply to Unity. I think maybe whoever suggested it was right, and it should have been called Unityscript.
–Eric