I mainly agree, tie is an excellent way to encapsulate data and complicated behaviors. The encapsulation is not as tight as you suggest, though. The tied call returns the underlying blessed object. No B&D OO in Perl!
Your example is perhaps a little too simple. The hardwired key in your setter and getter has to be rewritten for each class you want. That could be generalized by allowing the constructor to accept a list of keys and then generate the FETCH and STORE methods as per-instance CODE refs. The class FETCH() and STORE() would then just call the instance's stored method.
That begins to sound a lot like a pseudohash, but with a completely different implementation.
The alternative is to make FETCH() virtual by declaring but not defining it. The user could then subclass your Tie:: class and define it there, or else define it externally.
After Compline,
Zaxo
In reply to Re: tie for Perlish, encapsulated objects
by Zaxo
in thread tie for Perlish, encapsulated objects
by Roy Johnson
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |