As for n-deep lookups - whenever I see a lookup that's 2 or 3 deep, especially when mixing hashes and arrays, that is a signal to me that something can be abstracted out. It's the same case, actually. I automatically think of abstracting something out and would need reasons not to. I don't pendantically abstract everything out. I just feel that there would need to be a reason not to abstract vs. a reason to abstract.

Plus, I"m a little confused as to the tone you're taking with this whole dialogue. I may have been a little curt and know-it-all initially, but I apologized for that and have been attempting to clarify my initial position. I feel, and this is not meant to be a flame, that you have been deliberately obtuse towards me. Now, I appreciate the sustained and very direct questioning you've given me, as it's forced me to clarify for myself my position(s) on this matter. But, I feel I have made a number of good points regarding rules of thumb derived over years of experience. Yet, you haven't acknowledged them at all. Is there something I'm missing that you haven't made clear to me that would let me know where I'm stepping wrong with you?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Perhaps you intend to state things as rules of thumb, but that doesn't come across. You write for instance:

If you're within an object and you're doing 2- and 3-deep lookups into $self, you're programming horribly. It's mean, but true.

That doesn't sound as a "rule of thumb" to me, but a pretty rigid viewpoint. It's only after being remarked upon that you say something else:

I'm not advocating that all 2- and 3-level deep lookups are bad.

You also write:

In my eyes, you need to prove that a 3-deep lookup is necessary, within an object.

And in a next post, you write:

I'm not taking the position that it's a necessity or non-necessity.

For me, whenever I see ADT's, I automatically think of using objects and I would need reasons why they aren't necessary.

That's fine if it's your own code. But don't go preaching that everyone should be doing so, especially not in a thread where it would not solve the discussed problem. But perhaps your problem is:

I only skimmed the original post

Having good coding and design styles is good. But before you go preaching, open your mind for the alternatives; don't use dogma's but give reasons. And realize that what you find complex enough to wrap inside a method can be trivial for others. Also, keep in mind that while you easily grab to objects, others see Perl's OO system as being far from perfect.

There Is More Than One Way To Do It.

Abigail. (This will be my last post in this thread).

Don't forget recursion :)

Speaking of that, do you happen to know if perl does a tail-end recursion method kind of like Scheme (which interestingly enough doesn't have looping constructs :)