Re: Tied Variables - why?

[Arien]

I think tied hashes add an unnecessary layer of complexity that doesn't make much sense when you already have objects. ... You formally declare your behavior instead of hiding it behind the way that perl NORMALLY behaves.

What behaviour is there to hide when it's the usual behaviour you've come to expect of Perl?

The key to tied variables is to make them look so much like a regular variable that you forget what is going on underneath. Obviously, you can only get this to work if the behaviour you're trying to implement maps nicely on the normal behaviour of whatever your tieing to.

Your example shows what happens when there is a impedance mismatch between the behaviour you're implementing and how the variable type you've chosen for your tie normally works in those circumstances. The conflict with the expected behaviour is a result of using the wrong metaphor: you are luring the user into thinking all is normal, when in fact it is not.

As an example of a module, have a look at Tie::File, which does this (example code snipped):

Tie::File - Access the lines of a disk file via a Perl array.

Tie::File represents a regular text file as a Perl array. Each element in the array corresponds to a record in the file. The first line of the file is element 0 of the array; the second line is element 1, and so on.

The file is not loaded into memory, so this will work even for gigantic files.

Changes to the array are reflected in the file immediately.

Lazy people and beginners may now stop reading the manual.

Because you know how arrays work, you could now very likely start using this module without any problem whatsoever. If you had to use a "similarly coded class" you would still be going over the methods to see how things work in this particular case.

Now, that is the beauty of using tie.

— Arien

[Anonymous Monk]

So Perl intertwines expectations about behaviour with syntax.

We then find out that there are times we want something that is a lot like, but not quite, a native Perl data structure. The fact that there is no obvious way to do that is a self-inflicted injury, and magic is the band-aid that Perl applies.

But users often what behaviour that it a lot like something that Perl does. tie is a wrapper around the magic band-aid to give users a band-aid for that problem.

But people often want something that is a lot like something that Perl does, but not exactly! Which introduces tied - Perl's way to lift the band-aid and scratch the raw wound left beneath.

At some point I wonder whether it wouldn't be easier to just not injure ourselves in the first place?

[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...