Jump to content

Why Pixi doesn't respect encapsulation rules ?


SebKaine
 Share

Recommended Posts

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...