Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99188
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.65 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <edf37ea5-4643-f900-60c0-90df7a33b28b@fleshgrinder.com>
References: <e71637c6-db4a-7f29-ae08-89625eae8b53@fleshgrinder.com>
 <b471e706-6990-0543-7ee3-6ce1e9808c0a@fleshgrinder.com> <edf37ea5-4643-f900-60c0-90df7a33b28b@fleshgrinder.com>
Date: Fri, 26 May 2017 01:08:34 +0200
Message-ID: <CADyq6sLkEnkCd=2U8-n0VA7rUNkajwogtWWEmFCYUobFv_v85g@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="001a114199740928ea0550614e42"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: ocramius@gmail.com (Marco Pivetta)

--001a114199740928ea0550614e42
Content-Type: text/plain; charset="UTF-8"

On Thu, May 25, 2017 at 6:41 PM, Fleshgrinder <php@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/

--001a114199740928ea0550614e42--