|Do you know where your variables are?|
Re: RFC: Class::Proxy::MethodChainby Aristotle (Chancellor)
|on Feb 21, 2003 at 15:54 UTC||Need Help??|
I've thought about this some more, and written a few more examples.
This example shows the translation of using aggregate object accessors to the appropriate C:P:MC syntax:
I think it's easy to see that the latter syntax scales much better.
I had been thinking that the ->ret_val() syntax is just too bulky and was toying with the idea of having AUTOLOAD() extract pre(or suf)fixes from the called method's name. Eventually I decided against it - I don't think it's better as it'll only cover one case (albeit probably the most or second most common one - getting the return value of the last method call) and complicate AUTOLOAD() needlessly. A name change on C:P:MC's methods would do just as good a job without the added hassle.
I'm thinking of ->_ret() instead of ->ret_val() and ->_proxy() instead of ->ret_wrap(). ->ret_val() is horribly named to begin with, in retrospect - a function can return more than a single value, after all. I am leaning on ->_proxy() because ->_wrap() strikes me as indescriptive.
Now I know underscores are usually used for private methods and that's actually exactly the reason I'd like to use them here. It's unlikely that another module will expose public methods with such names, which minimizes the potential need to reach for the ->call() escape. For the same reasons I'm pondering renaming it to ->_call().
Of course all that means the ->wrap() constructor becomes ->proxy() as well for consistency and leads me to wondering if it's not maybe a good idea to make that one an exported function instead of a constructor. That way no C:P:MC method would start without an underscore, so collisions with wrapped object's public methods' names are far less likely.
Makeshifts last the longest.