Why do callbacks change context?

[dacatchman]

Why do you do this in Phaser?  For example, the preload/create callbacks, changes the context by using call and sets it to the game.

 

That just stomps on prototypal class structure, if for example, you wanted a class to contain a game object.   Should it behave this way?  Why not just pass a reference to the game as an argument, or allow the end user to handle it themselves and not force this?

[tips4design]

How would be helpful having the preload function with it's own context? First of all, this function should be internal and reserved and you shouldn't change how it gets called or you may break it. If you want a function with it's own context simply create another one. And it makes sense semantically for functions that change or add elements to the game instance to be used as methods of it's class.

[dacatchman]

I'm talking the user defined callbacks.

[drhayes]

I'm not sure what you're talking about. Phaser doesn't do that. Here's the assignment of callbackContext within StateManager. Here's preload getting called with that callbackContext, i.e your state. Unless I misunderstood..?

[dacatchman]

It's been a long day and I might just be overlooking the basics, but this seems wrong to me for some reason.

var MyClass = function() {var self = this;this.game = new Phaser.Game(1024, 768, Phaser.AUTO, 'game', {preload:this.preload});}MyClass.prototype.constructor = MyClass;MyClass.prototype.preload = function() {console.log(this); // <--- Phaser.Game, not MyClass}var app = new MyClass();

[tips4design]

Most of what I wrote is abstract non-sense, but this is my opinion.

 

Well, yeah this is a case where you could keep the context. But maybe the idea is that Phase.Game should be an enclosed system, with no direct access from external classes. With this in mind, your code could be refactored so that MyClass extends the Phaser.Game class, so that both the this for MyClass and this for Phaser.Game would actually refer to same thing. 

 

Think of preload, create, update functions as methods of the Phaser.Game class. When you use your functions for those methods, you actually overwrite the methods, thus making sense to keep the this context from Phaser.Game (it's like Phaser.Game is a class with a strict template in which you can only write code in some specified functions).

[drhayes]

In your example, "this.preload" isn't bound to your object instance, you're adding the function to a *new* object as the property named "preload". That object then gets linked by the StateManager and has a bunch of State properties. Here's a jsbin illustrating what I'm talking about.

 

Phaser does this thing when an object becomes a state where it adds a bunch of properties in a function called link. A bunch of those properties exist on a Phaser.Game instance, as well, which I think is confusing you. In that JSBin you can see that my custom property "doggyhat", which I added *on the object I gave to the Phaser.Game constructor*, is still present. However, the "catpants" property that I added to my MyTest class isn't present. The "this" of preload is not the game instance.

 

What you probably want is to pass "this" instead of a new object, e.g.:

this.game = new Phaser.Game(1024, 768, Phaser.AUTO, 'game', this);

[dacatchman]

Thanks Drhayes.  Still new to Phaser so this one tripped me up.