Hey guys, I’ve been searching on how to work with reference vars in Javascript, but I havent any luck.
what I’m trying to do is this:
void ToggleVar(ref bool t){
if(t){
t = false;
} else {
t = true;
}
}
So when I call the ToggleVar with any var I could declare, it automatically changes the var I’ve put inside the parameters of my ToggleVar function.
You can’t do that directly, but you can hack around it by defining a class, since classes are always passed by reference. Vote here. 
–Eric
The point of JS is simplicity
If you are a programmer, which is to be assumed if you know about ref and pointers, then C# is likely much better suited as it is a regular full featured programming language, not a special purpose language as UnityScript.
Once Unity is beeing updated to the new Mono versions (guess with Unity 3.x), you will also have some of the simplifications present in C#.
You will find various cases where you have an idea how something would be done in C# and will realize that you can’t do it in UnityScript (Properties, Ref passing, using Plugins, delegates, generics)
I wouldn’t expect that UnityScript will ever come anywhere close to C#.
It though definitely fullfill its purpose beeing an easy language for all designers and non programmers that are switching over from Action Script and alike and have no real background in programming.
Don’t be condescending. Also, try to understand that many people prefer Javascript, and it would do no harm for a few extra features to be implemented. Those who are beginners don’t need to know about them, but those who aren’t can use them.
–Eric
Fully understand that.
But its questionable how much sense it makes to replicate C# in UnityScript if C# already does it especially as part of what UnityScript makes that interesting to the users will come to C# too with a mono upgrade, making it simpler and more likely for more programming savy people to switch over.
Basic things like multi dimensional arrays are clear, they just need to work as they are required to use Unity.
But there are things where the replication is really of questionable use, especially as it takes a large amount of time just to dublicate already present functionality which in the end is used by only the “elite UnityScript programmers” which I would guess is a minority as the more professional users switch to C# which offers many more things, including generics and using 3rd party libraries with generics.
Also, with the documentation finally getting C# examples, the hurdle to use C# is much lower and that although it is already significantly easier to learn C# as tousands of tutorials and hundreds of books just offer more than a small community like Unity ever would create even if all were UnityScript users.
Learning a language is trivial; learning the Unity APIs and Mono/.net APIs are what take 99% of the time. So it doesn’t really matter how many resources for which language are out there, since the point of using Unity is using Unity, not completing a homework assignment or designing a database app.
JS already does 99% of what you need; it makes sense to implement, or finish implementing, a few more features so it’s comfortable for 100%. It’s true that when Mono is eventually updated, C# will get type inference, which will make things simpler, but Unityscript will always be more closely tied to using Unity (a number of small things like being able to use transform.position.x add up over time), so it’s just nicer overall.
–Eric
UnityScript is mainly good at hiding what it does.
Its not like US does anything different than C#, it just does it behind the curtain to save 2 lines in code while adding more overhead behind the scene as it won’t cache the property etc.
But yes, the basic functionality required to work with Unity definitely should be added
“Hiding what it does” = “More streamlined, elegant, easier to write code”. Excess complexity isn’t a virtue, and I don’t see C# being more generic as a virtue; I’d rather use something more specifically tailored for Unity. In critical cases, I can choose to do things the “hard way” to get a little more speed, and the rest of the time I don’t have to care (and those 2 lines of code add up to a lot when you have to do it over and over again). I’d rather have the choice instead of being forced to do things one way all the time.
It’s easier to write crappy code in JS if you don’t know what you’re doing, but if you do, it’s easier to write simpler and more elegant code…except for cases where you can’t use reference variables and have to make ugly hacks with custom classes, which is why that should be fixed. 
–Eric
Or simply do what I do, JS for some things C# for more things, its just things.
I’ve done that when necessary, but mixing languages can be a pain due to compilation order hijinx, so it’s best avoided unless you don’t need any communication between scripts.
–Eric
Yea, if you do what I do, make sure you dedicate a single language per object you attach the script to. For me, I have mostly all my C# code on EGO’s and JS code on actual game objects. Depends on if I am using plugin or not.
The entire point of an engine is to hide things and to assist. I don’t want to deal with pushing polygons to screen, or the intricacies of compiling shaders, or a million other things. Unity JS is perfectly aligned with this point of view.
It’s great that Unity supports other mindsets. There are people out there that use Resources.Load() for absolutely everything and eschew the Unity paradigms. More power to them, but they’re missing the point of Unity. Likewise, you can use C# if you want to do more work, and that’s all well and good, but in my opinion it too misses the point of Unity.
C# improves understanding at the cost of fewer abstractions. That is a rabbit hole that never ends. I will always choose more abstractions and less work instead of vice versa, because I want to produce things instead of do work, and that is why I love Unity so much.
P.S. And, yes, you can make a fair argument that if you produce things that, in turn, produce more things, you may want to knock off an abstraction layer or two. But I think it’s safe to say 95% of the people here are trying to make a playable game, and I believe these people should embrace absolutely every form of abstraction possible. If a differing mindset is in fact superior, it should be able to out-produce this mindset (and we produce an awful lot, so good luck)!
I think UnityScript has a few fundamental flaws that keep it from being robust enough to choose in large projects.
No abstract classes, no interfaces, errors using local variables in loops, bad reporting of some errors.
Delegates and such are not entirely important from my POV, but would also be nice.
We like using C# and find it makes our code more maintainable and portable.
That being said, its tomAYto tomAUTo.
Ok 
Thanks guys, I think I’ll have to use C#.
Cheers!
I’m not sure if the exact problem you had was how to pass in ref’s, or actually get that function working in JS.
If it was the latter, I’d recommend one of these:
var t : boolean = false;
// You could get the function to return the type
function ToggleVar(t : boolean) : boolean
{
if(t)
return false;
else
return true;
}
// then call the function like this
function SomeFunction()
{
t = ToggleVar(t);
// Or you could do something really easy like
t = !t;
}
90% of the time theres a way to do anything in each language (except generics, which is why I switched to C# ).