Extending Sprite class and adding private variables and methods.

[LuckieLordie]

Can it be done? I've posted my code with comments where I think everything should go but there has to be a better/easier way.

//class definition contains all public members?Player = function (game, positionX, positionY, playerSprite) {    Phaser.Sprite.call(this, game, positionX, positionY, playerSprite);    this.body.allowGravity = true;    this.body.gravity.y = 9.81;    this.body.bounce = new Phaser.Point(0.5, 0.5);};//private code for the class here? Needs spriteRef to access itself though :///inheritance stuffPlayer.prototype = Object.create(Phaser.Sprite.prototype);Player.prototype.constructor = Player;Player.prototype.update = function() {};

Cheers!

[jcs]

yes. it looks like you're on the right track. what is the problem that you're having?

(if your background is in traditional OOP languages the javascript equivalent is going to look a bit ugly, but that doesn't make it wrong)

[LuckieLordie]

yes. it looks like you're on the right track. what is the problem that you're having?

(if your background is in traditional OOP languages the javascript equivalent is going to look a bit ugly, but that doesn't make it wrong)

 

Yeah looking ugly is part of the problem Mainly that if I put my private variables where I place them there, wont they need a parameter to access the class it's supposed to be a part of? xD 

[jcs]

define private variables (fields) inside the constructor. fields in javascript are always accessed using 'this'

 

you'll get used to the language syntax - though you may never get to love it

[LuckieLordie]

define private variables (fields) inside the constructor. fields in javascript are always accessed using 'this'

 

you'll get used to the language syntax - though you may never get to love it

Cheers jcs you've helped me out

[rich]

There's no such thing as a private variable in JavaScript

 

(well, not on a language level anyway)

 

There are examples of extended sprites in the Examples Suite though, two of them in fact! Take a look at those maybe?

[jcs]

indeed, there are no private member variables. I should have said "member variables".

 

common convention dictates that fields whose names begin with an underscore should be considered 'private', so if you see members named this way in a library or class you are consuming, it is best practice to leave them alone.

 

(if you really want private fields you can emulate them with variables encapsulated in closures, but for most cases there really isn't a compelling need for them)

[brejep]

Take a look at: https://github.com/brejep/js-oop-test

 

It is an experiment I did with getting those 3 tenets of OOP - instantiation, inheritance and encapsulation - working in Javascript.

 

It seemed like a good solution but then I realised it messed up some things like instanceof which worked with the likes of John Resig's simple javascript inheritance and seemed important. At that point, I resigned myself to the fate of the Javascript developer - just pretending that stuff is private by prefixing it with an underscore.

[1-800-STAR-WARS]

You can sort-of simulate private variables using the module pattern.

var testModule = (function () {   var counter = 0;   return {     incrementCounter: function () {      return counter++;    },     resetCounter: function () {      console.log( "counter value prior to reset: " + counter );      counter = 0;    }  }; })(); // Usage: // Increment our countertestModule.incrementCounter(); // Check the counter value and reset// Outputs: 1testModule.resetCounter();// undefinedconsole.log(counter);console.log(testModule.counter);

[jcs]

(you don't actually need the module pattern - any variables captured by a closure become, in essence, private. this is how objects are implemented in scheme and the more traditional LISP languages. but the module pattern - or something like it - will produce something that more closely resembles an "object" from traditional OOP languages, this is true).