I’ve already filed a bug report, but it appears the keyword ‘not’ isn’t working in 3.0.
I’d never even heard of it. :?
!
!=
<>
Make your pick.
Never heard of this either. Are you guys just really drunk? :?
I think this may be an older language construct, as C# doesn’t seem to utilize it anymore. Back in the Borland C++ days, numeric comparisons can have <>, which is greater than or less than, or not equal.
I’ve never seen a “not” keyword in javascript OR C#, though.
lol I think ‘not’ is a VB keyword.
It is a lua, ruby, python keyword, though, too.
Unity uses a variety of “Python” called Boo, which unlike Python is a rigid-typed syntax. It may have dropped support for the not keyword, though.
[Edit:] On second pass, no, Boo has not dropped the logical not keyword.
Perhaps the OP is trying to use the not keyword in a script that is not being written in Boo/Python, and is instead using C# or Javascript, thinking that this is a ubiquitous concept.
[Also:] not not not not not not not not not not not not not not… Because I didn’t say it enough.
Me neither, but I just tried it and it does actually work in Unity Javascript, at least in 2.6.1. It may have been dropped because it’s not “supposed” to work, in either web Javascript or JScript (normally you’d use “!”, of course).
–Eric
Seems pretty stupid that it isn’t common. ! looks too much like I, l, and |.
Yeah, it doesn’t belong in the Javascript specification, so it’s likely an intentional removal for the sake of compliance.
Also, to the guy who posted before me, it’s not common because things have been done this way for years in the programming world… It doesn’t make it right, but software engineers are some of the least change-supportive people in the world… Which is silly because they work in an industry that changes daily.
Hah! This forum even renders the pipe the same way as lowercase L, although it shows up properly in the “Post a reply” box. :roll:
I doubt that. They’re not even calling it JavaScript anymore.
Bottom right.
.Net JScript. No, it’s not JavaScript, but it is JScript, which for all intents and purposes, is Microsoft JavaScript.
We’re getting into a Tomato/Tomato conversation here.
The Unity devs probably didn’t remove it. It was probably something that was handled internally by an older build of the Microsoft JScript.Net codebase, which was built into the new version of Unity missing the mistaken keyword.
Microsoft does have a history of pulling features that don’t come in line with the specification.
You obviously didn’t look at the second line of the link. UnityScript is mentioned several times. It is neither JScript nor JavaScript, as can be gathered from the lines including the name.
http://code.google.com/p/unityscript/
Correct indeed. Let me check out the source code and see what they’ve changed.
Unity Javascript is actually written in Boo. Despite being extremely similar, it’s not quite JScript.NET and certainly doesn’t have any Microsoft code, especially since it’s Mono we’re actually dealing with, not .NET.
–Eric
Well then, this certainly changes things. I’ve got some reading to do tonight.
http://mono-project.com/Scripting_With_Mono
From what I gather:
Unity is built on top of Mono, which is a managed C#-based program toolkit that allows for embedded applications to be run within the same context. Getting multiple languages to run in one context is a nightmare. Even a single scripting language is a nightmare when it comes to working out a design flow, but three at once? That’s unheard of.
Mono allows the multiple-scripting approach by creating a shared logic layer between the parsers and interpreters. Unity script is no more a unique version of Javascript than your editor script is a unique game development tool.
From what I can tell, Unity uses Boo to interpret Javascript… Which sounds like an absolute nightmare, to be honest. Once I got a proper build of the source, it started to come together.
So with this in mind, I’d probably say it was indeed a Unity “mistake” in putting in the not keyword in the first place. It could very well have been a parser mistake, and since it would be interpreting in boo anyway, it still worked properly.
No… Redirecting…
“Mono and .NET compile source code into ‘assemblies’. Assemblies, which are similar to collections of Java .class files, contain language-independent, platform-independent bytecode called CIL (Common Intermediate Language). Because assemblies are language independent, it doesn’t matter what language was used to create them. Assemblies made with C# can mix with assemblies created with VB.NET, Java (using IKVM), or any language that someone has written a CIL compiler for.”
–Eric
But that doesn’t change the fact that these assemblies need to be generated by machine-dependent source code in the first place.
You’re absolutely correct when looking at Stage 2, but I think we’re talking about different stages of compilation here.
Mono is using a JIT compiler, yes. But in order to boil down the code, there has to be a machine-dependent VM running.
“Unity is built on top of Mono, which is a managed C#-based program toolkit that allows for embedded applications to be run within the same context. Getting multiple languages to run in one context is a nightmare. Even a single scripting language is a nightmare when it comes to working out a design flow, but three at once? That’s unheard of.”
You will see here, that Mono IS a C based toolkit that essentially just compiles and executes code using plugin-based CIL compilers. Since it’s boiling everyting down to the same language, it does allow multiple languages to be run within the same context, because it’s still having to compile these syntaxes at runtime.
Not in the case of Unity iPhone.
For “obscure” platforms like that, I assume it is using the precompiled platform options in mono, yes?