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


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

Replies are listed 'Best First'.
Re^10: How could we "implement" Open Classes in Perl ?
by dragonchild (Archbishop) on Jun 28, 2008 at 02:47 UTC
    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?