Added pruning support in dir->recurse

[Mekk]

If recurse callback returns $item->PRUNE, no children of this item will be analyzed, mostly like $File::Find::prune=1

[kenahoo]

I like the idea, but I don't really like the magic return value. It relies on it being unlikely that someone would want to return that exact value for some other reason, but of course they may want to, for bizarre reasons (including malicious reasons, or because it's instrumenting Path::Class code, or something). Maybe there's some other way?

[Mekk]

I understand, that you are OK with syntax as such (return $item->PRUNE), but would prefer to use something unlikely (or, best, impossible) to be returned by callback accidentally.

I must say I do not quite consider chances that some existing code accidentally returns "PRUNE" to be too realistic, but it is of course possible to change this constant to something else, I will take a look (my first idea is to use reference to something, but if it would require too much code, some uuid-ish ugly constant would likely do to).

[Mekk]

I updated my changes, PRUNE constant is now reference to this very constant (address of PRUNE function), something unlikely to happen by accident and impossible to happen in legacy code.

PS As we I haven't mentioned this yet: I really like Path::Class idea, makes file&dir ops much easier to write, I regret I haven't discovered your module earlier.

[kenahoo]

I wonder if it's actually possible to just do $item->PRUNE and not have to do return $item->PRUNE. That's maybe too nitpicky though, and maybe too magical looking anyway.

[Mekk]

It is possible to do {{{$item->PRUNE}}} but I do not like the idea. Either it would return from the function (under the hood throwing some specific exception caught by {{{recurse}}}), or not (and in most cases the user will write {{{return}}} on the very next line). In both cases some code readers may assume alternate solution. I faced some such tricks (esp. in Python libs) and I do not like them too much...

[kenahoo]

Yeah, I think you're right.

[Mekk]

Any chances for CPAN release? Or do you need sth more to consider those fixes ready?

[kenahoo]

Thanks for the nudge - I've put a new release on CPAN.

-Ken

On Wed, Dec 5, 2012 at 4:18 PM, Marcin Kasperski notifications@github.comwrote:

Any chances for CPAN release? Or do you need sth more to consider those fixes ready?

— Reply to this email directly or view it on GitHubhttps://github.com/kenahoo/Path-Class/pull/9#issuecomment-11063479.