q{ But... isn't that a "surprise"? }. This is a fair point, but it's only a surprise if the user of my class expects a hash based implementation (the docs will soon correct this faulty guess ^_^).
In the case where he looks into my hash, he has decided to play with the underlying implementation details of my class and that's none of his buisness. It means I can't change how my classes work without breaking his client code, it also ties his code far tighter to my class and it's implementation, so he wont be able to later (painlessly) change to f00li5h::XS to gain the speed improvements it offers, or f00li5h::POE::Plugin to gain the cool poeness. Also, I may not be able to maintain a hash based interface when writing these new versions, so they may just never happen.
At very minimum, letting people play with your hash innards is using variables in your API, and that's frowned upon.
Although tricks with tie can allow my code to look like it's based on a hash, when it's not (kyle's Make an inside-out object look hash-based using overload.), but that's really best for porting, not for long term use...
In reply to Re^9: Method Chaining and Accessors
by f00li5h
in thread Method Chaining and Accessors
by linenoise
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |