Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^3: Is this DBM::Deep behavior, or something with tie/bless? (normal)

by dragonchild (Archbishop)
on Jan 31, 2008 at 05:17 UTC ( [id://665284]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Is this DBM::Deep behavior, or something with tie/bless? (normal)
in thread Is this DBM::Deep behavior, or something with tie/bless?

Is there a reason you want to untie the array? Generally, you just care about the data being on the disk and don't much care beyond that.

As for assigning the variable back to itself, it's generally frowned upon because it's usually a no-op. If it actually does something, then there's deep magic going on and, in general, deep magic is usually clever magic. Clever is the polite way of saying "stupid."


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^3: Is this DBM::Deep behavior, or something with tie/bless? (normal)

Replies are listed 'Best First'.
Re^4: Is this DBM::Deep behavior, or something with tie/bless? (normal)
by BrowserUk (Patriarch) on Jan 31, 2008 at 05:42 UTC
Re^4: Is this DBM::Deep behavior, or something with tie/bless? (normal)
by romandas (Pilgrim) on Feb 06, 2008 at 12:38 UTC
    The reason for 'untie'ing the array is related to my program using Data::Compare to compare data structures. The DBM::Deep database stores a hash of arrays (which have a hash as an element, etc). When my program runs, it retrieves the old info from the database to compare it with the new live information.

    However, Data::Compare fails when comparing the two arrays (old and new info) because the old array is tied to the DBM, effectively comparing data structures that aren't alike (my logical/mental representation notwithstanding) since DBM::Deep hashes and arrays are objects, I think, as opposed to the regular hash/array structure of the new information in memory.

    The two solutions I thought of (assigning the database array to a temp variable; assigning the new information to a temp spot in the database) both do not work (for differing values of 'do not work') due to the variables getting tied to the database.

    I could potentially write a plugin for Data::Compare to handle this, but from what I can see that is way beyond my current ability.

    I would post my code, but haven't finished writing it yet. :) The "variable reuse" problem (I believe) is just an artifact of my test code above; I don't think it'll exist in my actual code.

      Sounds like Data::Compare is broken. A quick peek at the source turned up exactly the type of broken code that I expected to see:

      if(ref($requires) ne 'ARRAY') {

      So just fix Data::Compare. The fixes would probably be quite simple. The best fix is to change such things to:

      if( ! eval { @$requires; 1 } ) { # Can't be used as an array re +f

      It is fine to use ref as a Boolean test. Any other uses of ref I simply can't recommend.

      Note that the above trick doesn't work for CODE references so you have to resort to one of the second-best methods. I'd use the following:

      *isa= UNIVERSAL::isa; #... if( isa( $ref, "CODE" ) ) {

      Note that this test can fail in the case of overloaded objects that want to pretend to be CODE references but that didn't bother to push @ISA, "CODE"; in order to declare this intention (which seems a perfectly reasonable restriction to me). chromatic would surely cringe and moan upon seeing such code because surely $ref->isa("CODE") is what should be used (except, of course, that it is likely to die in many cases). eval { $ref->isa("CODE") } might be a possible alternative but I thought it had its own drawbacks even though I can't recall what they were. My preferred method can also produce false positives if somebody intentionally lies via push @ISA, "CODE"; which I also consider to be a perfectly reasonable feature (which can even be useful when writing unit tests, for example).

      Looking at the code further, I see one spot that would be somewhat complex to fix because it assumes that a reference can only be of one type, which is not the case. But it would also simplify other parts of the code, because there would not have to be special code for looking under the covers of blessed references.

      Actually, perhaps it would be best to leave the plug-in handling alone, despite the flawed assumptions present there. Replacing the flawed assumptions with proper handling when considering handlers for specific classes of objects would be quite complex and you don't need to fix plug-in support in order to fix the basic flaw in the module; thus making it work fine on DBM::Deep results.

      Then the module becomes quite easy to fix (and the fixes still simplify some parts). The best route would probably be to write the following tiny helpers:

      sub isArray { eval { @{$_[0]}; 1 } } sub isHash { eval { %{$_[0]}; 1 } } sub isScalar { eval { ${$_[0]}; 1 } } sub isCode { UNIVERSAL::isa( $_[0], "CODE" ) }

      And then the less-tiny helper:

      sub getCommonRefType { my( $ref1, $ref2 )= @_; return "ARRAY" if isArray($ref1) && isArray($ref2); return "HASH" if isHash($ref1) && isHash($ref2); return "SCALAR" if isScalar($ref1) && isScalar($ref2); return ""; }

      - tye        

        So just fix Data::Compare. The fixes would probably be quite simple. The best fix is to change such things to:
        if( ! eval { @$requires; 1 } ) { # Can't be used as an array ref
        It is fine to use ref as a Boolean test. Any other uses of ref I simply can't recommend.

        Note that the above trick doesn't work for CODE references so you have to resort to one of the second-best methods. I'd use the following:

        Wouldn't that give a useless use warning? I would suggest this instead, which also works for CODE.
        if( ! eval { \@$requires } ) { # Can't be used as an array ref
        Pre-perl 5.10, either has a problem with arrayrefs being able to be dereferenced as pseudo-hashes.
        A few thoughts:
        • Those isX() methods belong in Scalar::Util (or something similar). I have similar snippets in DBM::Deep itself for the exact same reason.
        • You need to localize $SIG{__DIE__} within those evals. In doing this for DBM::Deep, I found Test::More does things with die handlers that get tripped up with this.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      I believe that you and I have spoken via email about this topic. I offered to support such a plugin if you would write the initial code and tests for it then hand it over to me. You never replied as to whether or not you would be willing to do so. Just throw some code together and hand it off - not too hard.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        You're correct; we have spoken in regards to this.

        I did reply to you that I would be willing to write up a plugin, if I felt confident I could do it. But, as my post above stated: "I could potentially write a plugin for Data::Compare to handle this, but from what I can see that is way beyond my current ability." Trust me, I am more than willing to help out in this regard if I can. As for writing up a test for DBM::Deep, I'm still trying to puzzle out exactly how tests work.

        All beauty and enthusiasm with no substance at this point, I'm afraid. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://665284]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-04-19 09:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found