Allow to modify options without creating a new object

[leofeyer]

Right now we need to create a new object instance every time we e.g. need a different regexp. This is cumbersome when using the library as a Symfony service, because it would require to define one service per configuration.

This PR adds methods to modify the options on the fly, so we can e.g. do this:

$slugify = $container->get('slugify');
$slugify->slugify('MY STRING', ['lowercase' => false]); // MY-STRING

TODO

• Add the unit tests

If you decide that you want to implement this, I'll happily add the unit tests.

[florianeckerstorfer]

This looks great. If you add unit tests, I will merge this.

[florianeckerstorfer]

I would add a return $this here.

[leofeyer]

Just so you know, this is just a workaround. It adds a state to the Symfony service, which one must not do. The correct solution would be this:

interface SlugifyInterface
{
    /**
     * Return a URL safe version of a string.
     *
     * @param string      $string
     * @param array|null $options
     *
     * @return string
     *
     * @api
     */
    public function slugify($string, $options = []);
}

You would then pass the separator as follows:

$slugify->slugify('My string', ['separator' => '_']);

This is not backwards compatible and would therefore have to go into version 3. But since the interface has an @api tag, I figured you do not want to change it anymore?

[Toflar]

This will put the Slugify service into a state and affect consecutive calls. This is wrong. It would be way better to allow the slugify() method to accept parameters. This can even be achieved in a backwards compatible way:

public function slugify($string, $options = null)
{
    // BC (2nd parameter used to be the separator string)
    if (is_string($options))
        $separator = $options;
        $options = [];
        $options['separator'] = $separator;
    }

    $options = (array) $options;

    // $options is now always an array and BC
}

The interface can be changed without affecting anybody as the method signature does not change.

[florianeckerstorfer]

You could also add a third parameter, options. Since this is BC we could do this in a 2.x release.

[leofeyer]

You cannot add a third parameter to the interface without everyone implementing it getting a method signature exception. But the solution @Toflar described would work.

[florianeckerstorfer]

You're right, I only thought about the implementation, not the interface. Yes, let's do it the way @Toflar described.

[leofeyer]

I'll adjust the PR.

[leofeyer]

I have updated the PR and also my initial comment to reflect the new usage.

[florianeckerstorfer]

Thank you very much for this PR. Great work.