Interesting. I always implement all methods in module as methods. Private or not.
Consider Dave05s example, he has two method _write and _read, now we agree these methods are private as indicated by the underbar.
However where I disagree with you is what this type of privacy means. To me this means that I shouldnt call this method directly (even though I can, method or function) probably because theres no error checking of parameters or some such equivelent reason. However this does not mean that I should not re-implement these methods as necessary in a sub class. In fact these are precisely the two methods that are the most obvious way to alter the behaviour of his class. If I am forbidden from reimplementing these methods I would be forced to reimplement new(),DESTROY() and add new _write() and _read() methods, effectively rewriting half of his class. But if I can change _write() and _read() directly then I dont have to change the published interface at all. new() would simply call the new _read and likewise with DESTROY.
Now I know there are different schools of thought as to how public and private methods should work, but I know from my experience in Perl that the modules that are the easiest to subclass (excluding those which are _intended_ to be subclassed) are those that have _all_ of their subroutines as methods, leaving the least overriding needing to be done.
Peace,
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.
In reply to Re: Re: Re: Re: Re: Tie-ing hashes clobbers data
by demerphq
in thread Tie-ing hashes clobbers data
by Dave05
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |