You are still coding your methods in your source code, so they are built at compile time, not run time, so you are not utilising any benefit of "open classes".

In order to make effective use of open classes, you need to dynamically determine not just the code that sits behind any given method name, but what that piece of code actually does. That is:

If you have something like:

package class;

sub metthod {
   ...
}

sub constructor or method {
    ...
    if( some condition) {
        *{class::method} = sub {
            ...
        };
    }
}
[download]

Then the function of both possible implementations is being determined at compile-time. The only runtime decision is which implementation is associated with the method named 'method'. And that means that you could just as easily, and far less obscurly, place both implementations inside alternate paths of an if statement conditional upon 'some condition' and the result would be exactly the same. You have made no useful use of the 'open class' concept.

In order to make use of open classes, the actual code that sits behind the method name has to be generated at runtime, based upon some piece of information not available at compile-time, not just selected. And I have yet to see a single instance of this in a real program.

As an example of what I mean, you might code the read method of a 'secure' transmission protocol so:

sub read {
    my( $self, $socket ) = @_;
    my $key = <$socket>;
    my $transform = $self->getTransform( $key );
    *{__PACKAGE_::read} = eval <<"EOC";
        sub { 
            (my \$in = <\$_[ 1 ]>) =~ tr[\x20-\xfe][$transform]; 
            \$in;
        }
EOC

    return $self->read( $socket );
}
[download]

The first time this method is called, it reads a key from the socket argument and derives a decryption transform from that key.

It then replaces itself with a method that uses that derived transform to decode all subsequent input from the socket. As the tables for tr are built at compile time, but the key is not available until runtime, there is no simpler way of doing this.

This would be an effective use of an open class, but I've yet to see a live example that couldn't be replaced with a compile-time equivalent.

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?

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."