in reply to Re: Recursive map Design Questions
in thread Recursive map Design Questions

Thanks for the Scalar::Util pointers

Im worried about the prototyping trick

I went down that path so that the leaf case could use the bare block syntax like a map. Also I wanted a variadic function and since the remaining args could be anything... there's not much room. I could have two entry functions, one for leaves and one with a hash mapping of functions.

I do like the minimal do {this} to @these ... Maybe 3 calling modes, leaf, prototype hack or sub hash. I'll think some more.

$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

Again, this was for aesthetics of the simple case. Most of the time you won't be cutting, just tweaking, or at least that the case I want to make easy. (It's also a design hang over from when it was more map-like and used the return value as replacement) Maybe die "cut" could be an appropriate out of band return value.

I don't like the name either. Still considering traverse, visit, for_tree, apply. I suspect that functional languages have a good name for this, I should research it.

Replies are listed 'Best First'.
Re: Re: Re: Recursive map Design Questions
by demerphq (Chancellor) on Oct 04, 2003 at 10:01 UTC

    I went down that path so that the leaf case could use the bare block syntax like a map.

    And I can see your point as well. You already have a wrapper function however. If the underlying implementation used a hash of callbacks then you could provide the neater codeblock style as well as the clunkier but more powerful hash of callbacks style as well. Everybody wins then.

    Maybe die "cut" could be an appropriate out of band return value.

    Yep, I can see that working nicely.

    Cheers,


    ---
    demerphq

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