Re(3): Tied Variables - why?

[Arien]

So Perl intertwines expectations about behaviour with syntax.

Quick, what does $bar = $foo{bar} mean? What does it do? How do you know, you've just seen syntax?

Perl lets you tie a behaviour to a particular syntax, because people relate syntax with behaviour. Using the right combination, this makes things easier because you raise the level of abstraction and reuse a familiar conceptual model including its syntax. It makes it appear that there is a special builtin type that eg. knows that you want the lines of a file as an array and lets you work with that array (conceptually and notationaly) just like any other array. How cool is that? :-)

tied is the way to get past tie's illusion and the only thing you'll find is that you were tricked, but you should have known that all along. That you need tied to remind you just goes to show how effective tie can be in creating the illusion in the first place.

— Arien

[Anonymous Monk]

You miss the point.

Suppose that you want to create an interface to a dbm. Making it look like a hash is an obvious way to do it. (If you try to do it with nested data structures you have trouble, but let's ignore that.)

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.

With this example in mind, here is my criticism. Perl's syntax creates a strong image of what a built-in datatype should look like. Built-ins are not extensible. tie allows a pretty effective illusion of a built-in. But if you have something that is a lot like a built-in, but its behaviour needs to be extended in some direction, Perl simply doesn't have a clean solution. Those two notions simply do not conceptually go together in Perl, looks native means isn't extensible and vice versa.

It doesn't have to be that way. For instance in Ruby the native datatypes can trivially be extended, and if you need a different implementation, then the MetaRuby package makes it easy to write new datatypes that behave like a built-in. This is the equivalent of tie except that no new concept needed for it, and there is no conflict between using it and extending the behaviour of your new thing in some interesting way that looks nothing like what the native datatypes do.

Of course you give up autovivification because the syntax no longer gives hints for the datatype. But then again you can swap between hashes and arrays more easily. And, of course, by not making it look hard you give up the appearance of being a genius for figuring it out...

[sauoq]

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.";