confusion about similar classes (input vs inputHandler, etc)

[Nebulocity]

A second question, is that the "useHandCursor" member is part of the Phaser.InputHandler class, yet we refer to it by using Input, which is a different class for all generic input operating within the game.  Using <sprite>.InputHandler.useHandCursor = true fails, yet using <sprite>.input.useHandCursor = true works.  Just a little confused on this, because I also see the same thing happening with classes such as Phaser.MSPointer and Phaser.Pointer, etc.

Phaser.InputHandler: The Input Handler is bound to a specific Sprite and is responsible for managing all Input events on that Sprite.

Phaser.Input: Phaser.Input is the Input Manager for all types of Input across Phaser, including mouse, keyboard, touch and MSPointer. The Input manager is updated automatically by the core game loop.

[rich]

Technically Input could be renamed InputManager, but it's the same end result.

[Nebulocity]

Technically Input could be renamed InputManager, but it's the same end result.

 

Right, but why does (InputManager) Input.useHandCursor work, and InputHandler.useHandCursor does not, when use useHandCursor is a member of InputHandler and not (InputManager) Input?  See what I mean?  It just confused me a bit, because I expected to be able to call a member from the InputHandler class, only to have it fail, and then in an example I saw that (whoever made that example) was calling the (InputManager) Input instead.  Just seems a bit backwards to call a member from what I assume is a parent class, rather than the child class it belongs to (if I'm even thinking about it correctly that way?).

[rich]

Because the name of a class doesn't have to = the property name.

 

I.e. this is totally valid:

var bob = new Phaser.InputManager();...bob.useHandCursor = true;

[Nebulocity]

Oh, I see.  Thanks for explaining it to me, Rich!