Re: How can I unbless an object?

[chromatic]

The idea of a 'curse' operator has been discussed on p5p from time to time. I seem to recall it's fallen afoul of rule #1, however. Larry doesn't like it.

Out of curiosity, what use do you see for such a feature?

[hossman]

It's never occured to me untill now, but i can definitely think of some cases where you may have blessed a refrence for use in some code (ie: doing OO) but when passing the ref to other code which drives it's behavior by the ref type of it's arg, you may want it to be treated as the underlying hash that it is.

I don't know if "curse" is really the right term for the case I'm thinking of (where you don't want to change the ref itself, you just wan a new ref to the same object with a different type ... which strikes me as being almost like a "cast" method...

   my $foo = new Foo;
   my $hash = cast 'HASH', $foo;
   print ref $hash; # 'HASH'

[merlyn]

but i can definitely think of some cases where you may have blessed a refrence for use in some code (ie: doing OO) but when passing the ref to other code which drives it's behavior by the ref type of it's arg, you may want it to be treated as the underlying hash that it is.

And all I can think of when I think of that is "bad design".

-- Randal L. Schwartz, Perl hacker

[ml340k]

use Scalar::Util qw(reftype);

using reftype instead of ref allows hash checking of an object from any class

[mp]

The intended use is to unbless deeply nested objects for use with Template Toolkit (TT2) so I can add/modify/remove fields in the hash before template processing.

If you pass TT2 an object that is a hash and tell it to access object.element_name, it will return

$object->element_name

if that method exists rather than

$object->{element_name}.

If I could unbless the object, then I could force it to use the latter. There are other workarounds, but if "unbless" existed in some form, it might be simpler.

[merlyn]

Ahh, yes. Since I'm so enamoured with Template, it's hard to scream "too much DWIMmery" there. But in this sense, yes, there's a mismatch between that DWIMish design, and what you actually want to hand to it.

Do you really need two-way communication? Can you not just hand it a copy?

If you do need two-way communication, perhaps you could hand it a tie'd hash reference, and then map that back to your object.

-- Randal L. Schwartz, Perl hacker

[mp]

I don't need 2-way communication, so a copy works fine and is conceptually cleaner. But it seems wasteful, since handing off the object to the TT2 process method is the very last thing done with the copy and the original object before they both go out of scope and disappear.

[perrin]

I think you are overly worried about the overhead of method calls. However, if you really want do this I recommend implementing a method on the object that returns an unblessed version of itself appropriate for use with TT. This gives you an opportunity to later do some extra magic in this method, like rearranging the data to make for a simpler template.

[mp]

In answer to my own question, I just discovered a recent CPAN module that can unbless an object. See Data::Structure::Util.