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

I'm also taking advantage of a few other facts in Javascript:

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?
  • Comment on Re^8: How could we "implement" Open Classes in Perl ?

Replies are listed 'Best First'.
Re^9: How could we "implement" Open Classes in Perl ?
by BrowserUk (Patriarch) on Jun 27, 2008 at 21:18 UTC
    • 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.
      100 objects, 100 functions, and zero attributes. There is a function that returns each object. It gets slotted into attributes that may have different names. But, it's the same code. You would think that there's actually 101 functions - 100 for each object and 1 for null. But, the 1 for null is already provided by the runtime.

      As for the "future-proof ploy", the key is that it doesn't cost me anything to do things a way that allows me to have options down the road. For example, I could have a maze that shifts over time through the use of secret doors, etc. Using methods, I just have to change the method and the effect occurs at the location of the change. Using a normal design, getLeft() would have to know about all the different possible scenarios. This means that getLeft() would have updated every time a new method of changing the connections between the rooms comes up. Using this method, a new method of changing connections could be added without getLeft() ever having to be aware that it was changed. All of a sudden, we have a plugin system without any work.


      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?
Re^9: How could we "implement" Open Classes in Perl ?
by BrowserUk (Patriarch) on Jun 29, 2008 at 23:03 UTC
    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>

    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.