in reply to Getting HASHES out of Class::DBI

Having done some Data::Dumper debugging lately, I've noticed that you could just cheat and derefence the object, assuming that you first do enough method calls to force it to be populated. (It tries to be intelegently lazy, so it won't always have all the data in it.)

If you want to be transparent to future changes in Ima::DBI or Class::DBI, though, don't use this method.


Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Replies are listed 'Best First'.
Re: Re: Getting HASHES out of Class::DBI
by hardburn (Abbot) on Jan 07, 2004 at 14:32 UTC

    If you want to be transparent to future changes in Ima::DBI or Class::DBI, though, don't use this method.

    I don't think this point can be emphisised enough: breaking the encapsulation on an object like that is a Really Bad Idea(tm). Even ignoring future versions of Ima::DBI/Class::DBI, all your inflate/deflate fields won't work (and I'm convinced that you should use them more often than not).

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      Amen and amen and ++ and ++.

      <soapbox>

      Breaking encapsulation should be only used as a dire last resort -- and certainly not in production code.

      Going uninvited into the innards of an object is like buying a car with airbags then disabling them, or removing your car's seatbelts. Yeah, you can do it, and eveything will seem fine for a while, and then something goes wrong and you get badly hurt.

      Objects are more than a funny way to call a useful subroutine -- they are an agreement between caller and callee as to a strict API, with everything behind the API wall treated as a black box.

      </soapbox>

      Apologies if I am preaching to the converted, the spirit moved me.