I’d like to report a couple of issues I’m seeing with the new 3.4 JS compiler, examples will make this much easier to explain:
If I have a function like so:
private var col : Collider;
private var bnds : Bounds;
public function setCollider ( arg : Collider ) {
col = arg;
// the compiler complains on the following line: 'bounds' is not a member of 'Object'
bnds = arg.bounds;
// I get the same complaint if I do
bnds = col.bounds;
// but if I do this it's ok
var newCol : Collider = arg;
bnds = newCol.bounds;
}
It’s not enough to have a class member with a strict type or an argument defined with a strict type… you need to define a local function variable with a type in order to satisfy the compiler that it really is a Collider type. This problem is not limited to just colliders… I’m also getting this as a problem as well:
private var customObj : CustomObj; // that extends MonoBehaviour
public function doSomething () {
var arr : CustomObj[] = 'assume this has a valid array of objects'
// local var used for two loops
var obj : CustomObj;
// first loop
for ( obj in arr ){
// complains 'transform' is not a member of 'Object'
var t : Transform = obj.transform;
}
// second loop
for ( obj in arr ){
// complains 'transform' is not a member of 'Object'
var t : Transform = obj.transform;
}
// I need to do this in order to satisfy the compiler:
for ( var obj1 : CustomObj in arr ){
var t : Transform = obj1.transform;
}
// second loop
for ( var obj2 : CustomObj in arr ){
var t : Transform = obj2.transform;
}
}
I can kind of understand the second one so that less work needs to be performed in order to work out what type the loop should use. However the first problem seems like an oversight, the compiler should not have any issues determining the types in the examples given.
Unsure if its an oversight, as the UnityScript compiler in 3.4 finally learnt basic access limitation and typesafety rules. To me it looks more like a vast number of JS codes were just written sluggishly and now backfire finally that the compiler is not or at least less bugged (every single JS based extension on the asset store I own for example has the problem or had it at the beginning of the beta before the compiler forced the devs to fix broken code which accessed private variables in other classes and alike)
This is taken from the Unity 3.4 JavaScript Upgrade Guide. I am just getting started in scripting. If this helps, please post back to explain how you used it.
"Unity 3.4 ships with an improved javascript compiler that supports better type inference heuristics for commonly used Unity APIs such as GameObject.GetComponent and Object.Instantiate as well as a stricter strict compilation mode (#pragma strict). The benefits are improved error checking and more efficient code generation leading to faster execution times. The downside is that in some particular cases code that compiles cleanly with Unity 3.3 might be (correctly) refused by the 3.4 compiler as in the following example:
// var definition in Foo.js
private var value = 42;
// attempt to use Foo.value in Bar.js
GetComponent(Foo).value = 21;
In Unity 3.3 the code above compiles without errors but 3.4 will complain with something similar to:
Assets/Scripts/Bar.js(2,18): BCE0120: ‘Foo.value’ is inaccessible due to its protection level.
That’s because the 3.4 compiler can infer the call to GetComponent to return a Foo instance and it can see that Foo.value is marked private whereas in previous versions precise type information was lost at the GetComponent boundary. The solution is to mark Foo.value as either internal (accessible only to javascript code in the same project) or public (accessible to any code anywhere) - removing the private marker will have the same effect as marking it public."
If I understand correctly, compilation mode is set to #pragma strict in 3.4 by default?
It’s not a requirement anymore to manually add this at the top of a script in order to enforce this mode?