The previous two replies are correct, but I believe it is also useful to observe that tie does "normal" OO, in the following sense: perl has intrinsic types — scalar, array, hash, filehandle — each with its proper interface which is exposed in the syntax of perl language. Sometimes we'd like to have a variable which "is" a hash (for example) but which has non-standard behavior. That is, in OO terms, we'd like to sub-class the hash type. tie is what gives us that ability. It just so happens that the implementation of the tie feature uses blessage, but that's a mere detail. It didn't have to be that way. (Of course, it is that way because it makes sense!)

So, looking at it from the other side, we can say that tie is how we get an arbitrarily complex object (typically in the form of a regular blessed object) to appear in the program as a variable. I would say that the only real limitation is that the tied (blessed) object has to implement the various methods of the base variable type — e.g. FETCH, STORE, etc. — but I'd be wrong. It only has to implement those bits of interface that actually get used in the program. (Perl, being so highly dynamic, is different from other languages in this.) So, for example, if your object supports the concept of accessing individual data elements by index, but not iterating over all such elements, your tied interface could implement the STORE and FETCH methods but not FIRST and NEXT.