making original file info available in callback for adhoc requirements

[swapnilsarwe]

@driesvints & @mallardduck ,

There are certain icon-sets which store the icons in the respective folder with the same file name.
Eg:

https://github.com/google/material-design-icons/tree/master/src/action/3d_rotation/materialicons/24.svg

All the files are named as 24.svg under respective folder with folder having the name of the icon.

From the above example, if I have the original file information available in callback, I can rename the file with an appropriate name using the file object passed in this PR

// from above example, lets say my source directory is dist/src/action/3d_rotation/materialicons/24.svg
Following is the callback method configured in after

$svgNormalization = static function (string $tempFilepath, array $iconSet,  \Symfony\Component\Finder\SplFileInfo $file) {
    ... 
    $fileMeta = explode("/", $file->getRealPath); // eg: dist/src/action/3d_rotation/materialicons/24.svg
    $svgFileName = $fileMeta[count($fileMeta) - 3];
    // now i can use this filename to change the name of the file as I need
    ...
};

Your thoughts?

[mallardduck]

Not a bad idea at all!

I sorta dislike that it has to be a breaking change - since other packages already use 2 parameter closures.
It's also unfortunate that there's no way to have a contract/interface for the callable to make it clear -before runtime- that the generator config will be invalid. It'd be nice if the IDE could be aware and telling us for instance.

🤔

[driesvints]

@mallardduck There's no breaking change here. Existing closures will continue to work as is.

Thanks @swapnilsarwe, I'll take a more thorough look at this as soon as I find the time.

[mallardduck]

@mallardduck There's no breaking change here. Existing closures will continue to work as is.

🤦 That's right - sorry forgot PHP does that as a feature rather than throwing an error.

[mallardduck]

@swapnilsarwe my only thought is around if you want just a string of the path, or the Spl object.
Not sure if it's consequential either way, but could be something worth considering.

[swapnilsarwe]

Sure. It works for me - atleast for my current use case. I can simply pass the string $file->getRealPath() instead of object of type SplFileObject.

I was just being little greedy by passing the complete $file object.

I will make the changes and update the PR.

[swapnilsarwe]

Have made the changes in the PR

[swapnilsarwe]

@mallardduck - have made the changes as you had suggested, i doubt whole object would be needed.

Thanks @swapnilsarwe, I'll take a more thorough look at this as soon as I find the time.

@driesvints take your time, i am using the forked version to generate icons in the specific packages where there is a need. They are just a few.

[driesvints]

I don't mind passing the entire file. Could be useful perhaps for other use cases.

Thanks @swapnilsarwe @mallardduck