|Do you know where your variables are?|
Abigail-II, you make several pertinent points, but there are also a couple on which I'd like to hear a little more about your thinking before I make changes to the tutorial (which I'd be happy to do).
1. I'm a little unclear as to whether you feel that I should simply have put in use strict in all my examples, or whether your are pointing out that using a hash_ref will not enable use strict to contribute much towards debugging, or both.
I was trying not to clutter the tutorial with any code that was not directly relevant to the OO aspects of the tutorial, so while I agree that all of these examples should use strict I was rather on the fence as to whether it would just be a distraction to the reader. Putting it the way you have makes me think I should stop being lazy with my examples.
2. With respect to hiding (full encapsulation via anonymous subroutines) I feel quite strongly that this belongs in an advanced OO tutorial such as this one. I don't believe that throwing closures into the mix will help people learn the fundamentals of how objects work in Perl.
3. This ties into my feeling that, while hashes have their limitations, they are the easiest way to introduce someone to OO in Perl. Are they ideal? No. Are they less complicated than arrays or closures? Yes. Again, this was never meant to be the canonical OO tutorial, just an introduction.
4. I realized that I was contradicting myself by saying that an inheriting class should never call a super class' private methods and then structuring my calls so that they *could* in fact call an inherited class' private method first, but wasn't thinking about the consequences of that decision in the way that you outlined them and was just trying to stick to the OO-style as a way of reinforcing usage.
Anyway, I agree with you and I think that I will change my code to use subroutine calls rather than method calls as soon as I can.
5. Use a different language -- I know what you're getting at here, but I think that pretending OO features don't exist in Perl is only going to lead to people doing BAD THINGS when they eventually discover it. People may pick up some bad habits here and there, but for the most part they (and those who have to maintain their code) will benefit from this feature more than they will suffer.