Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

File munge api #24

Open
wants to merge 4 commits into
from

Conversation

Projects
None yet
1 participant
Contributor

kentfredric commented Dec 30, 2010

This is mostly a request for a review of ideas and implementation.

If you like the concept , or think it needs work, get back to me =).

the idea is to unify the way people munge files, which currently has to be done differently depending on whether its a file from code, or a string file.

This doesn't appear to be a problem much at the moment, but if you try making a test or anything that gets moved/munged a File::FromCode, it will explode in a ball of fire when the munger tries to do

$file->content( $foo ) and the FromCode file is immutable in that context.

The Munge API simplifies this by making consumers interact with the content via a callback fashion, forcing a sub-ref, so the underlying infrastructure can do the right thing, and either modify the content now, or use coderef chaining so the files content is aggregated when its needed.

$file->munge(sub{ 
    my( $fileself, $content ) = @_; 
    return munged($content);
});

On normal files, the code runs immediately, on FromCode files, it chains it so its more like this:

my $orig = $file->{coderef}; 
$file->{coderef} = sub { 
     my $content = $orig->(); 
     return munge( $content );
};
Contributor

kentfredric commented Oct 7, 2011

I have thrown a bunch of tuits together and whipped up https://metacpan.org/module/KENTNL/Dist-Zilla-Util-SimpleMunge-0.1.2/lib/Dist/Zilla/Util/SimpleMunge.pm

A complimentary interface for munging files in a homogenous matter which has space in the code for defaulting to the changes suggested by this branch if wanted.

Currently covers the basic use case of simpifying the effort of munging any file in a consistent way, but will also have the option later to coerce lazy from-codes to immediate inmemories and vice versa depending on need.

Contributor

kentfredric commented Apr 26, 2015

I have a new idea here that might be more useful:

Instead of making the file nodes themselves contain mungers, the MungeFile role could have a stub like this, similar to its ->munge_file( $file ) for @files;

sub munge_file_content {
      my ( $self, $file, $encoding, $content ) = @_;
      return unless $file->name =~ /expr/;   #  No munge.
      return {  # Some kind of munging
         encoding => $encoding,
         content   => $content,
      };
}

I'm not sure if that design is viable or not, it seems to me there needs to be some kind of "mark for munging before actually munging it" step there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment