I disagree. Tied variables are a great way to create objects that look and feel like standard Perl variables but that change their behaviours in interesting and useful ways. It's true that most of the time you'll want people to use the "traditional" interfaces, but there will be a small number of cases where the things you want to do fall outside of that interface. I don't see that as an argument for throwing away the simpler interface completely.

Did you see my recent article at perl.com about tied hashes? There's an example in there of a hash with a fixed set of keys. When you tie the hash, you pass it a list of the valid keys. Most of the time you can then use the tied object as a normal hash. It's possible, however, that you might want to change the set of valid keys at some point in the application. There's no way to achieve that with the hash interface so you need to invent new object methods (note: Tie::Hash:FixedKeys doesn't do this yet, but I've been thinking of adding it). Most people will never need to use these functions, so I really don't want to make it harder for them to use the object by recasting it as a more traditional object class.

"The first rule of Perl club is you don't talk about Perl club."