Re^3: 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.

Comment on Re^3: eval-blocks and Test::Builder

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: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply] [d/l]
Re^5: eval-blocks and Test::Builder by fergal (Chaplain) on Feb 25, 2006 at 12:35 UTC
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.	[reply]
Re^6: eval-blocks and Test::Builder by Aristotle (Chancellor) on Mar 01, 2006 at 16:03 UTC
++ for the suggestion of keeping similar but separate things separate. Makeshifts last the longest.	[reply]