Boo and C# Namespaces?

Boo and C# classes seem to be in different namespaces – neither one recognizes the classes of the other. What namespace magic is required to have them see each other’s namespaces?

I think C# needs to be compiled first. Try sticking the C# sources somewhere in the standard assets.

http://unity3d.com/Documentation/ScriptReference/index.Script_compilation_28Advanced29.html

Maybe this article can help in detail:
Script Compilation

EDIT: Matthew… -looks like you were some seconds faster…
Though my link is nicer formated. :wink:

Thanks, all – it seems to be working so far. This seems to indicate scripts can only reference one-way, though; I can’t have Boo reference C# and C# reference Boo. (With the exception being SendMessage().) Is this correct?

While this may be stating the obvious, this solution is like eating stale bread. It fills the stomach, but it isn’t very tasty. :wink:

I think that’s correct. However I never used this feature.
Mix languages doesn’t seem like a nice thing for me.
I just recently translated a whole Javascirpt project to C#… :slight_smile:

Firstly, I would reccomend against having circular dependencies in your code in the general case, so being able to access a class A from a class B that is also accessed from the class A is generally a bad idea – even if they are written in the same language.

But it is possible through clever use of interfaces.

// C# code in standard assets:
interface IStuffDoer {
     void DoStuff();
}

class CSharpClass {
    public static MakeStuffBeDone(IStuffDoer other) {
        other.DoStuff(); // This will call DoStuff() inside the code that calls this function
    }
}
// Boo code
import UnityEngine

class NewBehaviourScript (MonoBehaviour, IStuffDoer): 

	def Start ():
		CSharpClass.MakeStuffBeDone(self);
	
	def DoStuff ():
		print "Doing stuff..."

This is a programming behavior, not something related to Unity.

When you program something that is needed by another block, it has to be compiled first. In C there is a way to say “hey, believe me, these functions are defined elsewhere, don’t try to find them now”, however in C# I don’t know if there is a way, or if there is in any other of .NET languages.

In C, if I recall correctly, it’s with the extern keyword.

I think that it is better to simply choose a language and use it on the whole project. I only used JS in the editor classes, since they were compiled first and I didn’t want to move my C# files around.

The other thing that you can do is create the Boo library outside of Unity and then drop the DLL in there. However, this only works for isolated blocks, no two-way conversation. Btw, some people say that two way dependency (i.e. A needs B, which needs A) is bad programming.

Regards,
Afonso

sorry to jump in and hijack another thread but i’m trying to understand this - i looked it up on wikipedia the page is a little light on details. so some interactions in unity-speak:

Example 1 (two separate GOs or same heirarchy):
-script a contains a var that with getcomponent references script b
-script b contains a var that with getcomponent references script a

Example 2 (two separate GOs):
-script a contains a var that with getcomponent references script b
-script b references a static var on script a

Example 3 (same heirarchy):
-script a broadcast messages script b
-script b sendmessageupwards script a

are these all examples circular references? why exactly are circular references bad? are they ‘not very elegant’ bad, ‘slows performance’ bad or are they ‘make your game an unstable buggy mess’ bad? (or am i just misunderstanding all of this ; )

Now I’m worried about this, too! :stuck_out_tongue:

If I have a button that spawns a message box, but then need the message box to let the button know when it’s been dismissed, isn’t that two-way dependency if the button holds a reference to the box and the box to the button?

I should really be working on my game instead of thinking about this, but there you have it.

I don’t see why mixing language should be a problem if you’re in a .NET environment; I’ve seen “true” .NET project on Windows using C# and VB (:evil:), interacting like a breeze, no SendMessage() mess or anything.
I’m still not too sure how Unity’s JS is compiled, but at least C# and Boo should interact since they’re both CLR languages. Maybe Mono is to blame?..

At least the “script compilation” link provided by Matthew and DynamicHead helped me understand an unanswered question: editor scripts are compiled too soon to have access to runtime scripts. So if you’re using a static class that isn’t attached to any GO (so you can’t use GameObject.Find() or anything), you’re screwed.

Unless you put said static class in the “Standard Assets” group. Boy is that messy… first thing I do when when I create a project is to move the standard/pro assets to a “~packages” folder so it doesn’t mess with my real project-specific assets, and now I learn this??.
Anyone knows if this is truly a folder name thing or is there some sort of marker on the folder that makes Unity’s asset database sort it out nicely?

Will we have namespaces in 2.0? THAT may be the way to organize all these compilation groups nicely.
The official page for 2.0 talks of a lot of nice eye-candy features, but there isn’t much info for us coders :cry: … the pariahs of the gaming world :wink: !

Hi,

Like in many thing in life, there are different ways to do something. Once in a while there are people that define some “rules”, and say that by using these “rules” you are doing that particular action in a “better”/cleaner way.

This is also true in programming, for example with indenting the code, using meaningful names for variables, etc. There are also some coding patterns (aka design patterns - Software design pattern - Wikipedia) that tell you how to program in a clean way.

Taking the example 1 - where obj A has a reference to B, and B has to A, the button example -, we could use the Observer pattern. A would reference B and register on B as an Observer. Everytime B changes, he says myObserver.notify(), and then B sees into A (e.g. sees if the button is pressed, or released) and does what it has to do.

Nowhere in B we have an explicit reference to A, we have a reference to a class called Observer, which A extends.

For example, if we need to have things done in both A and B, we can create an class C which has both A and B as references, and uses the Observer design pattern. Then, when A notifies C, C will see what the notification was and tell B what to do.

Although this is very nice and pretty, not many programmers follow these rules (especially when deadlines approach!), but they should because the code stays much cleaner. This is especially helpful when you have multiple people going through the same code. If things are clean, people will understand the code much faster (and it is much more scalable).

Hope I shaded some light on the subject!

As for doing things in both ASP.NET and C# in the same program, I haven’t done this, so I can’t really help you there. But MS’s .NET may have an “integrated compilation”, where you tell to compile everything and he can switch between compilers, but in mono you have different compilers for different languages, and the process is probably manual (i.e. you have to call mcs with c# files, and then the Boo compiler with the Boo files).

Regards,
Afonso

Ok, that explains a lot, Mono makes things more complicated I guess. Do you know anything about the place of Unity’s JS inside all this?
Thanks for the input!

I believe that JS is in Unity just like C# and Boo; they have a compiler and each time Unity starts a compilation process, it gets all the .js files and passes them into the JS compiler. This done in the precedence order of the folders. However, this is my outside view, only OTEE can tell you exactly what they do.

Regards,
Afonso

Wow, lots of discussion. Yes, circular references are less than desirable, but there should not be a restriction against code in two languages referencing each other (which is completely different than circular references). As was mentioned above, it’s not uncommon to have multiple languages used in a single project.

A while back there was this wonderful invention called a linker… :wink:

The real issue here for Unity is collaboration. One of it’s strengths is handling C#, Javascriptesque, and Boo; which means not everyone on a project needs to know the same language. That’s a good thing. :slight_smile:

Here is a hint how to easily use C# classes from Asset Store Tools with boo, i.e. NGUI: just move the entire folder of the tool in question in a folder named “Plugins” in the project view (Assets Folder). So they will be compiled earlier than your boo script and the classes are available in your boo script.