Interesting stuff. I think you have some potential zaps and traps with how you are identifying type and handling seen items. It looks to me that something like this would cause trouble:

my $x=\"foo"; my @array=("$x",$x);

As would any object with stringification overloaded. Can you see the havoc this would cause:

package Bitch; use overload qw("" bitch); my $bitch="Bitch0000"; sub bitch { $bitch++ }; package main; my ($x,$y); $y=bless \$x,'Bitch'; $x=bless \$y,'Bitch';

Also for this type of scenario don't use UNIVERSAL. I know this goes against common advice, but ref and UNIVERSAL are not meant for type checks except in the loosest sense. Just as Abigail-II correctly pointed out that an object of class '0' would cause trouble so too would an object such as would be returned by

bless [],'HASH'

With regard to BrowserUks point on this matter I generally agree that code need not worry about such nasty tricks. If an enduser wants to do such silly things then its their own fault. But with code deliberately designed to traverse a perl data structure correctly IMO should be coded to bypass such foolishness. Especially as it would not be particularly difficult to handle these cases.

What I would do is utilize Scalar::Util (now core as of 5.8), more specifically reftype() and refaddr(). Using refaddr is much more suitable for tracking seen items, and reftype provides a neat and infalable method of determinging an objects underlying type.

Im worried about the protyping trick. I think its cool on face value just for being tricky, but I think its a bit limiting. Why couldnt one provide a hash of types and callbacks for each? Also, $cut is a problem in my eyes. I think I would prefer to just have it return true or false rather than deal with this special variable in user code. (And File::Find and friends trick of localized vars isnt the best plan either IMNSHO.)

A few last minor thoughts are that I don't like the name of the sub (sorry), i prefer 'treemap' to 'do_rec' and I prefer 'apply' to 'treemap', and a little more documentation would have been nice. :-) It took me while to come to grips with what was going on. (IMO you shouldnt have to read the treemap thread first to understand your post... But maybe i'm just hungover. :-) Overall this looks pretty interesting, and leads me to return to thinking about the overall design of Data::Dumper and Data::BFDump. Good stuff. Thanks.

:-)


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi



In reply to Re: Recursive map Design Questions by demerphq
in thread Recursive map Design Questions by bsb

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.