Okay. Now take everything I say from here on in with a handful of salt because I've done little enough with javascript, and what I did do was a long time ago.
Let's say you have a 10 x 10 grid of these objects each with a getLeft(), getRight(), getUp() and getDown() (Yeah baby! :) methods.
That's 100 objects and 400 functions, no attributes.
But, if you gave each object knowledge of it's own position within the grid. Ie. if each had an x and y attribute, then you would only need 4 methods which took those x,y coords and returned the appropriate values based upon them.
So, you end up with 100 objects, 200 attributes and 4 functions.
Now, if you are calling those get*() methods a lot. then your method would avoid testing the boundary condition over and over, and that could add up to something significant in performance terms, and you would have traded memory for speed. A performance optimisation! Slightly faster, but simpler?
But, now try that another way. Instead of creating a function to return the adjacent objects, or storing the x,y pair as attributes. Store the adjacent objects as attributes.
Now you have 100 objects, 400 attributes and no functions. And no runtime condition testing! 400 object references has to take less space than 400 function references + the 400 code trees. And there are no function calls or runtime condition tests. You've saved memory and made the runtime faster still.
You can hold off on purchasing that octo-cored terabyte memoried superserver until next year's budget round. Or, if this is clientside js, then you've avoided alienating 50% of your potential market by allowing your app to run on their 4 year old hardware without upgrading :)
In reply to Re^7: How could we "implement" Open Classes in Perl ?
by BrowserUk
in thread How could we "implement" Open Classes in Perl ?
by Alien
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |