Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.219 cause and error)
MIME-Version: 1.0
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
 <b0f45799-94c6-3676-82ec-8667d8933211@heigl.org> <2cc94622-7f64-93af-c248-e82647e8053e@fleshgrinder.com>
 <1a596f98-cc6d-4e9f-b51a-3905fe1b0d97@heigl.org>
In-Reply-To: <1a596f98-cc6d-4e9f-b51a-3905fe1b0d97@heigl.org>
Date: Wed, 06 Sep 2017 07:19:42 +0000
Message-ID: <CANUQDCi4kPAJJYm3Cwi4y8oMv2ojNGg4vVQeHB3fV=A3UH=-KQ@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net, 
	Marco Pivetta <ocramius@gmail.com>
Content-Type: multipart/alternative; boundary="001a113b74969002ee0558802b14"
Subject: Re: [PHP-DEV] [VOTE] UUID
From: me@kelunik.com (Niklas Keller)

--001a113b74969002ee0558802b14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Di., 5. Sep. 2017, 21:32 Andreas Heigl <andreas@heigl.org> wrote:

> Hey Richard
>
> Am 05.09.17 um 19:29 schrieb Fleshgrinder:
> > On 9/5/2017 7:01 PM, Andreas Heigl wrote:
> >> Hey Richard, Hey all.
> >>
> >> Thanks for putting up the RFC and the implementation!
> >>
> >> Having UUIDs in the core would be awesome. One of the reasons would be
> >> that it's in C. That'd be faster but would also allow easier integrati=
on
> >> with system-calls to be easier able to get the MAC-Address for a type-=
1
> >> UUID f.e.
> >>
> >> But why limit UUIDs to type 3 through 5? Having security in mind is go=
od
> >> IMHO but not implementing type 1 and 2 limits the usability and
> >> therefore the usefullness. Let the users decide whether they need it o=
r
> >> not. As long as people can create SQL-Injections in PHP we should not
> >> use the security argument to limit usability or not implement
> >> standardized functionality.
> >>
> >> Especially when there is a full-fledged reference-implementation in
> >> userland available. In the RFC you reference ramsey/uuid yourself. But
> >> why should one use the internal UUID-class/functionality when there is=
 a
> >> more powerful one in userland available?
> >>
> >> And limiting the usability and extendability of the UUID-Class itself =
by
> >> declaring it final means that userland-code can only wrap the class bu=
t
> >> not extend it. So userland code can not typehint for the UUID-class wh=
en
> >> special features are necessary that would need extending the class. An=
d
> >> as there's no interface, I can't typehint for that either.
> >>
> >> So all in all for me that's
> >>
> >> * less functionality than the reference-implementation
> >> * missing UUID-types (the ones that are easier to implement in C)
> >> * missing extendability
> >>
> >> and a naging feeling that the imlementation decides what I as a user
> >> actually need.
> >>
> >> That's why I can't vote "yes".
> >>
> >> Sorry.
> >>
> >> Thanks for putting in the effort and coming up with a first
> implementation.
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >> PS: Personally I don't like a "uuid_4_create" as that would also mean
> >> there should be a "uuid_1_create" through "uuid_5_create" as well and
> >> then there also would need to be a "uuid_1_verify" through
> "uuid_5_verify"=E2=80=A6
> >>
> >
> > Hi Andreas!
> >
> > Thanks for your feedback.
> >
> > We can easily add v1 and v2 because the class is final. It would not be
> > a breaking change, or anything. v2 is pretty much useless imho, but v1
> > if done right would not even harm your privacy.
>
> I'm with you there in so far that I personally don't see a value in a
> type 2 UUID. But there might be people that need exactly that. And as
> adding functionality usually isn't a BC-break that's OK.
>
> >
> > Composition is more powerful than inheritance. You mention that you
> > cannot extend it to add functionality, at the same time you want to
> > type-hint against it. Well, in order to use the extended functionality
> > you need to type-hint against your extended version. Hence, there is
> > zero value for you in extending it other than having some place using
> > the extended version, and others the core version without noticing that
> > it got the extended version.
>
> I'm well aware of that and perhaps I didn't express myself as clear as I
> should have.
>
> Imagine a use-case where a UUID-class is needed. But alongside the
> toString, toHex and toBinary there's also the need for a further
> function (let's call it toArray). So currently I need to create a
> wrapper arround UUID that then needs to implement all the public methods
> of UUID as well as the new toArray. So it works identically to UUID but
> it isn't UUID. And I have no way of using my own UUID-Class - as it
> doesnt' extend UUID - as replacement for UUID. I'd need to expose the
> wrapped UUID-Class to be able to retrieve it whenever some libray
> expects a UUID. Perhaps this gist can make it clearer:
> https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa


How about a simple function that takes an UUID and returns what you want?
People often forget that they exist in PHP.

Regards, Niklas


> >
> > The thing is, you should create your own value objects for your
> > identifiers and hide the fact what it wraps. In C, and many other
> > languages, we have type aliases. In PHP, and many other OO languages, w=
e
> > use composition to achieve tha>
> > Whether to make it final or not was discussed, and especially Ocramius
> > agreed with me on this. I believe that it is the right choice.
>
> I'm not saying it's the wrong choice. I for myself would probably not
> immediately use it as the ramsey/uuid-package is widely in use, but I
> could f.e. think, that that package might start to use the UUID-class
> under the hood. And then that would be a case where extending could be
> helpful as a \Ramsey\UUID would be an instance of \UUID.
>
> The alternative would be to implement a UUIDInterface that exposes the
> relevant methods and that would be implemented by \UUID itself.
>
> But that's just my 0.02=E2=82=AC
>
> Cheers
>
> Andreas
>
> --
>                                                               ,,,
>                                                              (o o)
> +---------------------------------------------------------ooO-(_)-Ooo-+
> | Andreas Heigl                                                       |
> | mailto:andreas@heigl.org                  N 50=C2=B022'59.5" E 08=C2=B0=
23'58" |
> | http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
> +---------------------------------------------------------------------+
> | http://hei.gl/root-ca                                               |
> +---------------------------------------------------------------------+
>
>

--001a113b74969002ee0558802b14--