Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^2: When should a wheel be reinvented

by tilly (Archbishop)
on Jul 01, 2004 at 02:16 UTC ( #370962=note: print w/replies, xml ) Need Help??

in reply to Re: When should a wheel be reinvented
in thread When should a wheel be reinvented

You cannot generally wrap a callback interface with a looping interface unless you have continuations, co-routines, or some other similar construct. Perl does not. (Well, there is a module that adds it, but I'm not sure what issues it has. Certainly it isn't a built-in feature.)

Whether it is good for a language to have continuations is another debate, and there are top-notch people who'll argue both sides of that choice.

Regardless, Perl 6 will have continuations.

  • Comment on Re^2: When should a wheel be reinvented

Replies are listed 'Best First'.
Re^3: When should a wheel be reinvented
by etcshadow (Priest) on Jul 01, 2004 at 02:22 UTC
    Here, here. See this node for some further discussion (which, in fact, also happens to mention File::Find and it's callback-based interface).
    ------------ :Wq Not an editor command: Wq
      If you're motivated, I'd suggest trying to find some of Dominus' comments on File::Find. His opinion seems to resemble yours - File::Find works well except that the API can be very inconvenient. IIRC his book (which should be coming out really soon...) on higher-order Perl implements an iterator-based equivalent to File::Find.

        Honestly, I'd really rather not see yet another implementation of directory traversal in perl. What I think would be the ideal is to have just one implementation (let it stay File::Find, everyone already knows it!), but have that implementation be usable with each of these types of interface:

        1. callbacks
        2. declaratively (by that I mean: my @files = File::Find::find(...); or something similar)
        3. iterator

        Presently, File::Find provides 1, directly. File::Find::Rule and its ilk provide 2 (as a wrapper around File::Find... which is great, because that means no one has to replicate the directory traversal code for that). The thing that's missing is a good iterator interface, and, again, that can't be built as a wrapper around File::Find.

        So of course, the best possible thing (in my opinion) would be if someone rewrote File::Find so that it (internally) had an iterator interface:

        my $finder = File::Find->new($opts, @dirs); while (my $file = $finder->next) { # do stuff }
        And then, finally, to change the old familiar File::Find::find(...) to be implemented as a simple wrapper around File::Find's iterator interface:
        # simplified a lot, but basically sub find { my ($opts, @dirs) = @_; $opts = wrap_wanted ($opts); my $wanted = $opts->{wanted}; my $finder = File::Find->new($opts, @dirs); while (my $file = $finder->next) { local $_ = $file; local ... # etcetera &$wanted } }
        So you'd get:
        • all the benefits of each type of interface
        • the directory traversal written (and optimized and maintained, etc) only once
        • nothing gets broken (all we've done is to refactor and to add new functionality)

        Of course, I feel bad demanding this, without volunteering to do it, but honestly, it would create legal complications if I were to do so (I've got one of those contracts where my employer owns everything I do... at least for the moment, but I've been promised that that will change at least somewhat by the end of july). But I still think that the "most best" approach is clear enough that it's worth setting down (even if I'm not going to go off and implement it myself).

        ------------ :Wq Not an editor command: Wq

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2021-04-21 12:07 GMT
Find Nodes?
    Voting Booth?

    No recent polls found