Small fixes

[llvdl]

No description provided.

[coveralls]

Coverage decreased (-0.007%) to 96.44% when pulling 7e204ed on llvdl:small-fixes into dbd275b on slimphp:3.x.

[coveralls]

Coverage decreased (-0.007%) to 96.44% when pulling ca50316 on llvdl:small-fixes into dbd275b on slimphp:3.x.

[coveralls]

Coverage increased (+0.06%) to 96.502% when pulling 593280b on llvdl:small-fixes into dbd275b on slimphp:3.x.

[danielgsims]

There may be a conflict with type hinting the methods as an array. The FastRoute RouteCollector::addRoute method accepts a string or array of strings of http methods. This is the only place I think we use the Route::getMethods function. So technically, even though the phpdoc documents an array of strings, if you use a string everything should work. This could be a BC break.

[coveralls]

Coverage increased (+0.06%) to 96.502% when pulling 1ac6460 on llvdl:small-fixes into dbd275b on slimphp:3.x.

[llvdl]

@danielgsims, thanks for looking into this. The framework seems to consistently call Route with an array of methods, but the Route constructor is public, so this could be BC.

I have removed the typehint and added a check in the constructor to convert the parameter to an array if a string is passed. This way Route::getMethods always returns an array, as stated in the docblock. The docblock of the constructor is changed so it is clear that either a string or an array can be used.

[danielgsims]

Maybe go make a note on the Slim 4 road map discussion!

[akrabat]

Why add support for string?

[llvdl]

Because FastRoute supports both a string parameter and an array of string. Because there is no array typehint on $methods, string was already supported. I updated the docblock to reflect this.

Also, when setting Route::$methods in the constructor, the value is set to an array, so Route::getMethods() always returns an array as stated in the docblock.