Different scope to callback [Advanced]

Unity Engine
1

Hi

Any hackers to help me figure out a workaround to a tough problem?

What I’m trying to do (illustrated with web javasciript):

var x = {name : "Foo"};
var y = function() { alert(this.name); }
y.call(x); // Alerts "Foo"

But when in JScript.net i try to do the same:

...
function y() {
  Debug.Log(this);
}
y.Call([x]); // prints out the parent class of y, passes x as argument

Of course my approach would be possible with Function.call on .NET Framework 5.5, but since Unity’s using only .NET 2.0, i’d really need a workaround.

Any ideas?

2

What’s wrong with

function PrintName( x : Object ) {
  Debug.Log(x.name);
}

It looks like Y functions identically to a member function of X’s class.

Just call X.function instead of y.function(x)? I just don’t see the advantage of all the indirection.

3

well, you can’t have that exactly… anyways it results in a weird syntax in the code.

There is extension methods though… like this:

(this is C#)

public static class ExtensionMethods
{
    public static void PrintName(this object obj) { Debug.Log(obj.name); }
}

public class Foo
{
    void Start()
    {
        this.name = "Fart Knocker";
        this.PrintName(); //'this' is implicitly passed in, and 'Fart Knocker' is logged
    }
}

This can accomplish a similar task for you, allows for a cleaner syntax, and should probably accomplish the same design you’re looking for.

For other fun hacking you should look into ‘anonymous functions’ and ‘reflection’. This again is C#. Not exactly sure what features unityscript/javascript supports. I know it has access to the reflection library, I know it can’t do extension methods, I don’t know about anonymous functions.

4

Thaks for the replies.

Yes, this was exactly my approach: I tried to set the scope of an anonymous function, so I could do:

myArray.each(function() {
  Debug.Log(this); // Just prints anonymous function's parent class :(
});

But instead, I was forced to pass the object itself as reference, which just makes code more ugly:
(I know, it’s perfectionism)

myArray.each(function(_this : System.Object) {
  Debug.Log(_this); // prints correct reference
});

And, like said, it’s very easy to do in .NET 5.5. Could C#'s reflection class etc. give some nice writable caller/parent property?

5

umm, how does that make it more ugly?

You still have to pass in the object… you just have to define the parameter in the function. You think defining the parameter in the function is ugly?

I think it’s ugly that you use the name ‘_this’, but aside from that, having the parameter is not ugly IMO. With the parameter defined you know what is going on. Otherwise reading the code you’re always wondering which ‘this’ ‘this’ is referring to as it’s not actually ‘this’ but instead some non-‘this’ you passed in to a function that isn’t even shaped to accept a ‘this’… UGH.

See ugly is a bad word for this. Ugly implies preference of look. I could think spaghetti code is pretty to look at from an abstract artsy point of view. But from a practical point of view it’s bad code.

What you’re suggesting is bad code. It may be pretty, it may be ugly aesthetically… but programmers will call it ‘ugly’ or ‘smelly’ or ‘code stink’ because it’s BAD CODE. And it’s bad code because it’s not readable.

6

I would disagree, because the beauty of this particular code comes straight from jQuery’s syntax.

I’m currently helping some of my web developer friends to understand and become more familiar with Unity, so I’m porting basic jQuery functionality to Unity.

So if one has used to type:

jQuery("tag").each(function() {
  jQuery(this)....
});

it’ll definitely look more ugly to them to have something like:

jQuery("tag").each(function(_this : System.Object) {
  jQuery(_this)....
});

Then again, beauty is in the eye of the beholder :wink:

7

That’s kind of what I was pointing out. Beauty is the wrong word to use here.

That is called code stink.

jQuery, though useful, is notorious for its code stink. Javascript in general is known for its code stink. Unityscript follows the ecmascript standard (and is not actually javascript), the ecmascript standard is the standard that jQuery breaks. Unityscript furthermore is an implementation of ecmascript to compile into mono, so it also follows those standards too… which this breaks as well.

And in standard programmer parlance, code stink is a synonym for ‘ugly’.

See javascript w/ jQuery in the end doesn’t really follow any object-oriented standards. It breaks nearly all the rules. But because no one expects object-oriented behavior in javascript, they get away with it. ‘this’ doesn’t mean the same thing there necessarily.

In mono/.net, this means a whole lot more and to remain readable the standards of it must remain standard. Once it becomes unreadable… well that’s ugly. Again, using the word ugly in standard programmer parlance, meaning ‘unreadable’.

So in the end. Answer to your original question. NO, you can not accomplish what you desire, because Unity is not javascript running in a browser breaking rules with jQuery to remain compact.

You don’t have the bandwidth limitations, so all the rule breaking jQuery commits is not justified.

But C# offers other more elegant tools to accomplish similarish results, while not being unreadable.