... and situation, and available time. Ever since I got the hang of using deeper/heavier data structures in perl, I've become more and more reliant on being able to handle more problems with less code in shorter amounts of time. Usually, the design is "simple" in the sense of optimizing the access to data for a particular activity: fewer looping blocks are needed overall, and the ones that are needed can be more compact, when the data are well organized for the task at hand.

I do worry sometimes about taking things too far, stuffing too many different things into one structure, and pushing the code to the point of being too obscure. But it often turns out to be a self-correcting condition -- if the data structure gets too complicated, so does the code that handles it, to the point that a self-respecting perl programmer will balk at that and start looking for a simpler alternative.

I agree that there should be a "shallower" threshold for drawing the line on depth/obscurity of data structures when building an OO design -- or at least when putting together an object's API.