in reply to Re^2: eval-blocks and Test::Builder
in thread eval-blocks and Test::Builder

I'm not familiar with DBM::Deep but are you really expecting to have a $_[0] that's a Contextual::Return object? If _get_self is a method in the DBM::Deep::Array package then I don't see how any of the edge cases you have catered for could actually happen.

Replies are listed 'Best First'.
Re^4: eval-blocks and Test::Builder
by dragonchild (Archbishop) on Feb 25, 2006 at 03:07 UTC
    A couple of the features that we're working towards are subclassibility and multiple engines. Which means DBM::Deep::Array could be subclassed by something that masquerades as an array using Contextual::Return or some other class that overloads @{}. Why should I prevent that when I prefer to use code that ducktypes $_[0] vs. explicit-types it?

    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?
      Why should I prevent that...

      Because it leads to lots of debugging and meditations about unexpected pitfalls :)

      Another possibilty is to create DBM::Deep::Array::Tied and bless tied arrays into that and untied into DBM::Deep::Array. Then you get 2 _get_self()s both of which are crystal clear.

        ++ for the suggestion of keeping similar but separate things separate.

        Makeshifts last the longest.