It's, at the very least a doc bug, in that the POD doesn't have this limitation in the CAVEATS. I originally thought it was an implementation bug, but the author responded and said it wasn't.
So sorry, but DBM::Deep doesn't handle objects (i.e. blessed hashes). It only supports anonymous hashes and arrays. Anything blessed will not be stored blessed. I considered adding this feature, but many
classes don't appreciate having their hashes tied. Its on my to-do list for a future release, however.
I think it can be done, but that requires maintaining a separate metadata structure which may require a complete redesign of the file layout.
The Perfect is the Enemy of the Good.
| [reply] |
Well, I read the very same docs you did (I presume), and I never got the impression that it would store objects. Interesting how we saw two entirely different things in the docs.
And frankly, I wouldn't want it to store objects. The design is clean... adding blessings alongside would clutter up the protocols needed to access the existing metadata. If you send it an "export" call, should it be DBM::Deep's export, or the native object export? That's the kind of confusion you'd get by permitting objects in the mix.
| [reply] |
As usually, you're absolutely right. The docs should still be explicit about the fact that this will not store objects. :-)
The Perfect is the Enemy of the Good.
| [reply] |