Go back to the if-elsif-else! Stringy eval should be a last resort!
Besides, treating all of the references the same doesn't make much sense. Sure, I can see wanting to allow both @array and [list], but if you end up wanting to support refs to hashes, then it is unlikely that what you'll want to return is %$href (more likely you'll want to return just the keys or just the values, or have the hash keys have meanings...). And what possible value is there to allow \$value instead of just $value?? Or for letting the user pass in a code reference rather than forcing them to be the one to dereference it?
Sure, I've written functions where if one of the arguments is a code ref, I take special action. But that special action is never to just call the code in order to get the list. That would be a waste!
Even for the list vs. ref-to-array cases, I'd usually end up going the other direction: turning the list into an array ref! The whole point of allowing someone to pass in a reference to a list is usually that the list might be quite long and you don't want to have to copy that big list of values just to pass them to some subroutine. But your code just causes lots of extra copying to happen so just don't support refs to anything if that is all you are going to do with them!
(:
- tye (but my friends call me "Tye")In reply to (tye)Re: Eval and $@% ...
by tye
in thread Eval and $@% ...
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |