Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <e47a2c34-b6f3-66de-1f03-6753d5b1d4ea@fleshgrinder.com>
References: <e71637c6-db4a-7f29-ae08-89625eae8b53@fleshgrinder.com>
 <CA+kxMuTV7p14HbDpEQrwJKG3soUgxXV5BEs6WHgPtSOmjc2grQ@mail.gmail.com>
 <f9c91d81-097b-680e-904a-126ffee16b19@rhsoft.net> <ba50cf2d-6744-e78f-18be-e1d65990f0d9@garfieldtech.com>
 <CAFMT4NpNmkpfcWXsMydxDbULV9iNTe9BJxYdFdHdD1H36P1p6w@mail.gmail.com>
 <be5db50a-bc70-2cfe-5a0a-dc0ef15360ba@fleshgrinder.com> <CADyq6sKta5ngCkQc3tZZ5Pw3GqW93Lk283ofeuPMf6c7fjyCLg@mail.gmail.com>
 <e47a2c34-b6f3-66de-1f03-6753d5b1d4ea@fleshgrinder.com>
Date: Wed, 24 May 2017 20:47:11 +0200
Message-ID: <CADyq6sLvmYS0oqhSTzq13V-9604WSOdqmaeM5yVGhgQGKpjjxQ@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045f50d66a7ccc05504989b6"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: ocramius@gmail.com (Marco Pivetta)

--f403045f50d66a7ccc05504989b6
Content-Type: text/plain; charset="UTF-8"

On Wed, May 24, 2017 at 8:39 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 5/24/2017 8:09 PM, Marco Pivetta wrote:
> > For once, I must say that I disagree with having an OOP API defined in
> core.
> > This can exist in userland, so it probably should. Internal classes,
> their
> > reflection, behavior, inheritance model, etc are full of quirks.
> > There's nothing wrong in returning a string, then having a userland lib
> > make it into a UUID value object: it actually is better for everyone's
> > sanity.
> > It would (probably) be better to stop at the function that actually
> > generates the identifier, then having the boxed value defined in userland
> > anyway. Yes, we lose the type hinting, but damn are internal classes
> ugly.
> > If you must keep the object style, make it `final`, so at least we won't
> > have people extending this thing for no good reason at all :-P
> >
> > Marco Pivetta
> >
>
> The problem with procedural APIs is, especially with the way the PECL
> UUID is implemented, that you are constantly converting back and forth.
> While OO allows you to encapsulate your things.
>

Yup, converting is indeed problematic.


> There is actually only a single thing that is not (yet) possible with
> Reflection on internal methods: getting the default values of a
> parameter. I wrote Reflection tests for every single thing, to ensure
> that it works as good as possible. Have a look at the `definition.phpt`
> test cases:
>
> https://github.com/Fleshgrinder/php-src/tree/rfc/
> uuid/ext/standard/tests/uuid


That's actually awesome! Well done, this pretty much nullifies my fears


> Here is one where I had do comment the default value thingy:
>
> https://github.com/Fleshgrinder/php-src/blob/rfc/
> uuid/ext/standard/tests/uuid/UUIDParseException/__
> construct/definition-005.phpt#L15


Ok, this is inherited API that is broken in all libraries anyway due to
default value reflection, so I guess it's good to go.


>
>
> And yes, everything is `final` to ensure that nobody can do anything
> with the classes. This applies to the `UUID` and the `UUIDParseException`.
>

Thanks!


>
> Furthermore, I carefully crafted everything to be as close to userland
> as possible. No magic, none at all. I use default PHP built-in stuff for
> everything. Even the parameter parsing is 1:1 as it would be if you
> would define the very same class in PHP.
>
> I will extend my signature with "No Magic!" now. ;)
>

Perfect, this absolutely makes it a huge :+1: on my side.

Last thing I'd suggest is to grab Ben Ramsey and get him to check the patch
:-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--f403045f50d66a7ccc05504989b6--