Why Pixi doesn't respect encapsulation rules ?

[SebKaine]

Hi guys !

 

It's my first post here, so first of all hello to everybody !   

I am reading all your very informative input , and it help a lot to discover Pixi.js.

 

I come from a Python/C++ background and i am learning Js/Pixi trying to apply my previous skills to it.

 

The big thing that bother me with object oriented programming in Pixi, is that it doesn't respect encapsulation.

You have access in each object to all the methods, but also to all the properties. And this is really weird for me,

cause to me exposing properties to the user is Evil, because you have no way to check consistency of the

user input.

 

For exemple in Exemple 6 - Interactivity you have :

var button = new PIXI.Sprite(textureButton);button.buttonMode = true;button.position.x = 175;button.position.y = 75;

Basically we are directly accessing an Object properties, without checking the integrity of the input.

Position properties is set in the DisplayObject Class

PIXI.DisplayObject = function(){    this.position = new PIXI.Point();...}

Why do the use of accessors is not the norm in javascript. There must be a reason that justify this, but i am pretty javascript ignorant at the moment

so i would like to understand ?

 

Something that looks more logic to me, would have been:

PIXI.DisplayObject = function(){    // private    this._position = new PIXI.Point();...}PIXI.DisplayObject.prototype.move = function(x, y){    // check the integrity of x and y    ...    // if integrity is ok move (to x,y)    this._position.x = x;    this._position.y = y;};

Thanks for your help and Time !

 

Cheers

 

Emmanuel

 

[xerver]

I come from a Python/C++ background and i am learning Js/Pixi trying to apply my previous skills to it.

 

The big thing that bother me with object oriented programming in Pixi, is that it doesn't respect encapsulation.

You have access in each object to all the methods, but also to all the properties. And this is really weird for me,

cause to me exposing properties to the user is Evil, because you have no way to check consistency of the

user input.

 

Welcome to javascript. There is no sure-fire way to prevent people from accessing any property in js (except by scoping which has perf/maint/etc implications). That is generally why we just properties on the object that users have access to, it isn't a PIXI-specific thing it is pretty standard in js.

 

JS does have the idea of C# style getters/setters. That is, functions that run when a property is read or assigned (think assignment operator overloads for the setter). Problem is, using these incurs function call overhead so we only want to do it when we *need* to do extra actions when a property is set. Ensuring you don't throw a string into the x property of a point is not the job of the library it is a responsibility of the user. The types of checking you are describing are honestly just not necessary, and so their overhead isn't worth it.

 

This can seem very strange coming from langs like C++, but JS is dynamic and prototype-based. If your object has a property, I *can* access it. Period.

[SebKaine]

Many Thanks for your Help Chad ! it looks that You help Me one every Pixi Forum !

 

So if i get things clear :

- true properties encapsulation (@private) is impossible in javascript

- like in python js use a naming convention for properties that must stay private : _properties

- using accessors ( getters / setters ) is perfectly possible but the overhead it represent is not justify

 

So basically

- in js every C++ setters / getters are replace by direct access to properties for better simplicity / efficiency of the code.

- properties with private notation < _properties> are those that must stay hidden to the users.

[msha]

Private properties can be emulated using closures - https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Contributor_s_Guide/Private_Properties#Using_Closures

But it's usually not recommended.

[xerver]

Many Thanks for your Help Chad ! it looks that You help Me one every Pixi Forum !

 

So if i get things clear :

- true properties encapsulation (@private) is impossible in javascript

- like in python js use a naming convention for properties that must stay private : _properties

- using accessors ( getters / setters ) is perfectly possible but the overhead it represent is not justify

 

So basically

- in js every C++ setters / getters are replace by direct access to properties for better simplicity / efficiency of the code.

- properties with private notation < _properties> are those that must stay hidden to the users.

 

Pretty much, like I mentioned you can have "private" objects by basically creating variables in a scope you have access to but outside users do not. But for simple properties you add call overhead that for high-perf applications (like pixi) we try to avoid. If we make x/y of point a getter/setter and did type checking we would probably cut out fps in half since those properties are used so often, many times each frame.

[SebKaine]

Thanks again for all your input Guys !

 

 

for simple properties you add call overhead that for high-perf applications (like pixi) we try to avoid. If we make x/y of point a getter/setter and did type checking we would probably cut out fps in half

 

Max perf is exactly what i am searching for ...

 

I also note that three.js use a very close programming style to yours. When the 2 best webGL librairies, follow the same way of doing things, you suppose that their choice is motivated ...

 

Javascript is really a strange beast , i coudln't tell that i hate it cause it is not as bad as i was tell, but some aspect are extremely weird at the begining ...But it's harder than what i was expecting , you can't just dive directly in Js with C++ knowledge ...

[whitetigle]

Now, you could use a language like Haxe (haxe.org) on top of js to give you encapsulation and all class sugar candies.

You would code in Haxe and it would generate the js code and so get everything clean and typed.

[SebKaine]

Thanks for your input whitetigle !

 

I also heard about coffee script, but for the moment i think i will focus on pure Js to get a very good understanding of the language.