One big piece of advice. If you do this, I would want to see the exporting be controllable from user code. For exactly the same reason that Exporter says to use @EXPORT_OK instead of @EXPORT, and why it is unfortunate that some of the classes in the IO* hierarchy did an @EXPORT of huge lists of thing. (An export that can never now be changed because of backwards compatibility. Ick.)

And a comment. The fact that a native data-type is not easily tied and then extended is one of the things I dislike in Perl, and is a necessary result of the decision to embed the type system in the syntax. (Don't get me wrong. I like Perl. But nobody can criticize like family, if you know what I mean.) I far prefer the approach that is being taken in Ruby of making all of the native data types objects, and then providing mix-ins which make it easy to produce your own classes that have all of the methods to work where a native datatype does.

So you just create a class, create the same methods a tie would need, and then import a mixin, and your class now looks like a native data type. Now add more methods at will. You now have all of the power and flexibility of tie, with all of the extensibility of an object, and without having to build any special support for it into the language.

tie is, after all, nothing more than a hack to make an object look like a native data type. Just make your native datatypes be objects, and you don't need the hack. Not needing the hack means that you don't get the bugs associated with having a hack like that. (Perl's tie implementation has a lot of bugs. For a random instance it does not cooperate with local. For others see bug reports by people like danger and tye.)