Now suppose that your dbm offers some useful features that hashes don't - like granular locking for cooperation between processes. How do you expose that naturally? You can't extend the tie solution to do it. The available behaviour for a hash is fixed by Perl's syntax - to get something with extensible behaviour you have to make it obviously extensible from the start. The native datatypes aren't. So you either tell people to peek using tied (wrecking the illusion) or else (more efficiently) you don't pretend to be a hash from the start.
You could choose to use the object returned by tie to get at the extended functionality in the cases where you need it. Or perhaps you determine that this case isn't a good one for using tied variables at all.
Tie isn't a silver bullet but it is one more tool in the toolbox. In a case where it makes sense to implement a class to act like one of Perl's basic datatypes it is a very useful tool indeed. Determining where it makes sense is left as an exercise to the reader. In the long run, experience will help make the decision, but as a general guideline, do it where either all of the functionality or the most common functionality easily fits the abstraction.
-sauoq
"My two cents aren't worth a dime.";
