in reply to Re^5: How could we "implement" Open Classes in Perl ?
in thread How could we "implement" Open Classes in Perl ?

In Javascript, I have used the fact that the objects are open in order to simplify logic in a 2-D grid. Instead of having the neighbors (left, right, up, and down) as attributes, I close over them in the accessors. Something like: 
for ( var i in x ) {
    for ( var j in x[i] ) {
        if ( i > 0 ) buildLeft( x[i][j], x[i][j-1] )
        else buildLeft( x[i][j], null );
    }
}

function buildLeft ( obj, target ) { obj['getLeft'] = function () { re
+turn target; }; }

[download]
And so forth. This means that I can have simplified code later on down the line.
My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^7: How could we "implement" Open Classes in Perl ?
by BrowserUk (Patriarch) on Jun 27, 2008 at 15:44 UTC

    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 :)

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I'm also taking advantage of a few other facts in Javascript:
      • Methods are attributes. There is no inheritance in JS, meaning that every object has a direct reference to every one of its methods.
      • Identical functions are referenced (in most implementations). This means that identical code gets a reference to the existing version, not a new function.

      I could store the adjacent objects as attributes, but that prevents me from expanding my object model later on if, for some reason, the getLeft() method isn't static anymore. This future-proofs me.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
        • This means that identical code gets a reference to the existing version, not a new function.

          Okay. That reduces your solution to 100 objects, 364 functions and zero attributes.

        • This future-proofs me.

          <voice type="clouseau"> Ah ha! The old it-future-proofs-me ploy. Very good. </voice>

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Identical functions are referenced (in most implementations). This means that identical code gets a reference to the existing version, not a new function.

        Hm. Quite hard to verify this, but I've succeeded in disproving it for 3 browser-based implementations and 2 standalone.

        If you load the following into a browser, and click the "allocate array" link, and check the memory consumption when the "Hi there" alert is displayed, you'll see the memory consumed by an array of 10000 references to a single function. 

        <html>
    <head>
        <title>Javascript test</title>
        <script type='text/javascript'>
            var func = function () { return 12345; };
            var size = 100000;
            var array;
            function allocateArray() {
                array = new Array( size );
                for( var i = 0; i < size; i++ ) {
                    array[ i ] = func;
                }
                alert( 'Hi there' );
            }
            
            function populateArray() {
                for( var i=0; i < size; i++ ) {
                    array[ i ] = function () { return 12345; };
                }
                alert( "How's it goin'?" );
            }
        </script>
    </head>
    <body>
        <a href=# onclick=allocateArray()>Allocate array</a>
        <a href=# onclick=populateArray()>Populate array</a>
    </body>
</html>

        [download]

        If you then click the "populate array" link, and again check the memory when the alert is shown, you'll see the memory consumed when those function references are replaced by references to an "identical" function that's declared in-line.

        If the JS interpreter was intelligent enough to recognise that the implementations are identical and somehow 'contant fold' them, there would be no increase in the memory consumption. The reality is, it at least quadruples in every implementation I've tested.

        BTW. It's really not a good idea to iterate arrays using for( ... in ..) as you do in Re^6: How could we "implement" Open Classes in Perl ?. See the highlighted box here for details.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom