I see what you are losing - you have significantly complicated your life so you can slow down every access by an order of magnitude. But OO is not good just because it is OO. There is nothing magical about the method-call syntax that makes it better. It is just a different way of saying the same thing with a little polymorphic magic.
Now there are many things that you could do which would make the tie make sense. For instance often you want to have a different implementation look like a tie. An example would be to have an object with a set of keys that it would use (so that typos of a key would trigger a warning). Another would be a hash that was stored persistently on disk. Yet another would be an interface into a C structure. In each of these cases the tie is winning you something specific - something that in all likelyhood has little directly to to with the capabilities you want to expose.
In that case it makes no sense to intertwine the package that you tie the hash into with the package that has methods you are exporting. Indeed you drop this incestuous relationship as chromatic suggested and your problem just goes away.
My suggestion therefore is to simply drop the tie. If at a later point you find a need for it, you can easily add it. Probably it will just be a matter of building your tie implementation and modifying the constructor.
Remember that the point of modularity, interface hiding, and all that isn't that your first implementation will be gold-plated. Rather it is that you can get a working system and then be able to modify it in directions that experience shows are important...
In reply to Re (tilly) 1: DESTROY for tied classes
by tilly
in thread DESTROY for tied classes
by MeowChow
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |