On Thu, May 25, 2017 at 6:41 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:

> On 5/25/2017 4:45 PM, Fleshgrinder wrote:
> > RFC is finished
> >
> > https://wiki.php.net/rfc/uuid
> >
>
> Would it be possible that we discuss the open issues, instead of trying
> to get rid of the proposal completely? I will not back up anyways after
> investing so much time. ;)
>
> https://wiki.php.net/rfc/uuid#argument_parsing


Saw the discussion on github, and I wish that the argument parsing just
behaved like a *NORMAL* PHP method.

The following is perfectly valid:

$crapTonOfUuids = array_map([UUID::class, 'v4'], range(0, 1000));

This would raise a lot of warnings if the API didn't behave like it does in
userland (warning on too many arguments).
A point was raised about BC compliance when adding parameters (future
scope), well here's the news: stop adding arguments to existing functions,
make some damn new functions/methods/classes (to whoever still thinks that
adding arguments is a valid decision).


> The argument parsing is a huge problem together with return type
> constraints. Would love some feedback here from nikic. Even if this does
> not get included, the issue will pop-up with the next implementation
> that wants to use return type constraints.
>
> https://wiki.php.net/rfc/uuid#final_class
>
> I am not sure about the final class modifier. Would love some feedback
> here from Ocramius.
>

The UUID type and specification is simple and clear.
Also, a UUID is a data type with no real behavior.
The only possible and valid scenario for subclassing would be to add
semantic meaning because the developer invented a new type of UUID: that's
to be excluded, as such an implementation (if relevant and secure) would
land in core anyway in future PHP releases.
Subclassing to alter behavior (generation/serialisation, if you want to
call them "behavior") would be a mistake that could even lead to security
issues, and it should be avoided.
This class should be final, so keep it final, IMO.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Reply via email to