Re: Find images regardless of filetype extension.

[merlyn]

Let's see. Reinventing File::Find (in core) and Image::Size (in CPAN). Let's leverage instead of reinvent:

use File::Finder;
use Image::Size;

my @starting_points = qw(.);

my %images = File::Finder
  ->type('f')
  ->gather(sub {
    my($x, $y, $type) = imgsize($_);
    $type ? ($File::Find::name, $type) : ();
  }, @starting_points);

[zzspectrez]

Yes, all true... But not nearly as fun, nor nearly as educational.. Actually not using any other module was the point for me creating it. Perl is my hobby, not proffession and I find many times the best way to learn is to reinvent and usually more fun. I'm not trying to leverage anything :)

I would appreciate any comments on code quality, if you have any. I personally do not see anything wrong with reinventing the wheel as long as you know it's not necessary. However, many times it is done poorly. Hopefully that is'nt the case here.



zzSPECTREz


P.S. File::Finder --> interesting wrapper! I think I will have to check that out.

[merlyn]

But not nearly as fun, nor nearly as educational. Actually not using any other module was the point for me creating it.

Fine, then post it here with "I know there are ways to do this with a few modules, but one of my design goals was to not use modules". Otherwise, I waste a lot of time trying to figure out why you didn't use modules, which is a silly goal for production code.

I would appreciate any comments on code quality, if you have any.

Well, let's just start with the inefficiencies and errors of these two lines:

        my @files = map { "$dir/$_" } grep { !/^\.{1,2}$/ && -f "$dir/
+$_" } @tmp;
        my @dirs  = map { "$dir/$_" } grep { !/^\.{1,2}$/ && -d "$dir/
+$_" } @tmp;

Let's see. Twice as many stats as you need (because you can get whether it's a file or a dir with one stat). Breaks on files named "..\n" (because you'll reject that with your regex match needlessly). So there's a bug and a misfeature, just in those two lines.

I personally do not see anything wrong with reinventing the wheel as long as you know it's not necessary.

I do. You've posted this code here. Some crazy fool is going to cargo-cult your code without paying attention to your design goals or the following commentary. And that puts more bad Perl code in the world, not good code. {sigh}

[zzspectrez]

Fine, then post it here with "I know there are ways to do this with a few modules, but one of my design goals was to not use modules

Fair enough. I think I should add that as my standard disclaimer since I have a habit of doing that quite often.

Twice as many stats as you need (because you can get wether it's a file or a dir with one stat).

I was aware that there had to be a better way to end up with both @files, @dirs with one test but was and still am unsure how to do it. What do you suggest? Really... I was hopping for some code suggestions/improvements

Breaks on files name "..\n" (because you'll reject that with your regex match needlessly).

Where in the world are you going to find an image named '..'. I tried to create a file named '..' on windows and it will not let me. Regardless, I agree if you can create a file named '..' it will miss it, but is that really break it?? It's a bug that will silently ignore such file at most, correct? Really... I have seen mention of this before, but have never understood what the problem is. Is the problem eliminated with the use of !/^\.{1,2}\z/??

I do. You've posted this code here. Some crazy fool is going to cargo-cult your code without paying attention to your design goals or the following commentary. And that puts more bad Perl code in the world, not good code. {sigh}

merlyn, you need to stop worring about crazy people. No matter what anyone does they will still be crazy and eventually shoot themselves in the foot. :) However, this discussion has shown me some things I would not have been aware if I had not posted it.

I think I understand your frustration, however I disagree with your ideas on coping with it. The standard use CPAN response is valid but does not lead to people who know how to write better code. They do write better code because the bugs that would have been in their implementation are not there. However, they do not understand why their version had bugs. I think it keeps them as cargo-cult programers who just know how to do the routine to get the results they want. They do not grow. Im trying to grow. Telling me bad boy, dont rewrite. Will just keep me writing bad code in this world. However, If you tell me what Im doing wrong I will (hopefully :) ) learn from my mistakes.

THANKS

zzSPECTREz
My Standard Disclaimer