Using Clone::Any nowadays is more trouble than it's worth.
First, there are annoying incompatibilities between cloning modules. Most notably Storable, which is the default cloning module if Clone is not available, *still* doesn't support storing Regexp objects out-of-the-box after all these years.
Second, this module has not been updated for a long time and newer alternatives like the fast Data::Clone is not recognized.
Right now I'm replacing all code from using Clone::Any code to Data::Clone.
1 out of 1 found this review helpful. Was this review helpful to you? Yes No
Clone::Any / Clone-Any (1.01)
It's easy to use, flexible, bundle of joy, etc. etc. and I would give it five stars, but....
If I just used Clone, it would work on most platforms (seems to have passed 26+ tests with no failures) and has no pre-reqs.
But if I use Clone::Any, it failed tests on at least one platform (this may be the specific machine it was tested on and not the module's fault, though) and it requires Devel::UseAnyFunc and a separate module capable of cloning.
So my choice is to specify using Clone which requires just installing Clone, or I could use Clone::Any, which requires installing Devel::UseAnyFunc and another module for cloning (such as Clone, though Storable is now a core module).
It seems like a great idea to just have the module look for whatever cloning routine is available on the system and use it transparently, but it is more work than just installing Clone. (If it were part of the core, that would be something else, but then again, one could just as well speculate if Clone were part of the core...)
One other potential problem: if I use Clone::Any instead of Clone, Storable, etc., then I risk that code doesn't work consistently across systems because of bugs in one cloning module on some platforms that is not in the other cloning module. If I at least use a specific cloning module, then I've eliminated some potential problems.
0 out of 1 found this review helpful. Was this review helpful to you? Yes No