Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.89 cause and error)
Reply-To: internals@lists.php.net
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net,
 Marco Pivetta <ocramius@gmail.com>
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
 <b0f45799-94c6-3676-82ec-8667d8933211@heigl.org>
Message-ID: <2cc94622-7f64-93af-c248-e82647e8053e@fleshgrinder.com>
Date: Tue, 5 Sep 2017 19:29:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <b0f45799-94c6-3676-82ec-8667d8933211@heigl.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="mjcl9URQg9JcUc2RT2PeXXUeVF2N5nq4S"
Subject: Re: [PHP-DEV] [VOTE] UUID
From: php@fleshgrinder.com (Fleshgrinder)

--mjcl9URQg9JcUc2RT2PeXXUeVF2N5nq4S
Content-Type: multipart/mixed; boundary="ed6QQxsC9tk6ua2IgN6dJ7JVL21SUn60D";
 protected-headers="v1"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net,
 Marco Pivetta <ocramius@gmail.com>
Message-ID: <2cc94622-7f64-93af-c248-e82647e8053e@fleshgrinder.com>
Subject: Re: [PHP-DEV] [VOTE] UUID
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
 <b0f45799-94c6-3676-82ec-8667d8933211@heigl.org>
In-Reply-To: <b0f45799-94c6-3676-82ec-8667d8933211@heigl.org>

--ed6QQxsC9tk6ua2IgN6dJ7JVL21SUn60D
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/5/2017 7:01 PM, Andreas Heigl wrote:
> Hey Richard, Hey all.
>=20
> Thanks for putting up the RFC and the implementation!
>=20
> 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 integratio=
n
> with system-calls to be easier able to get the MAC-Address for a type-1=

> UUID f.e.
>=20
> But why limit UUIDs to type 3 through 5? Having security in mind is goo=
d
> IMHO but not implementing type 1 and 2 limits the usability and
> therefore the usefullness. Let the users decide whether they need it or=

> 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.
>=20
> 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?
>=20
> And limiting the usability and extendability of the UUID-Class itself b=
y
> declaring it final means that userland-code can only wrap the class but=

> not extend it. So userland code can not typehint for the UUID-class whe=
n
> special features are necessary that would need extending the class. And=

> as there's no interface, I can't typehint for that either.
>=20
> So all in all for me that's
>=20
> * less functionality than the reference-implementation
> * missing UUID-types (the ones that are easier to implement in C)
> * missing extendability
>=20
> and a naging feeling that the imlementation decides what I as a user
> actually need.
>=20
> That's why I can't vote "yes".
>=20
> Sorry.
>=20
> Thanks for putting in the effort and coming up with a first implementat=
ion.
>=20
> Cheers
>=20
> Andreas
>=20
> 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_veri=
fy"=E2=80=A6
>=20

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.

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.

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, we
use composition to achieve that.

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.

--=20
Richard "Fleshgrinder" Fussenegger


--ed6QQxsC9tk6ua2IgN6dJ7JVL21SUn60D--

--mjcl9URQg9JcUc2RT2PeXXUeVF2N5nq4S
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZrt8QAAoJEOKkKcqFPVVr6xUQAJflaLXjzQJhzxItdgwHBN/E
lbT9pJev73OWGciKQ3YNt6L7uip+1SQnH5DpJkdfl0PXDcUlJ9xz+9laRk8JFCms
iU4W9+Jquhz3yI6mJEMfpMuTvrcNWWGWE5/YDmCEtkgiQ5DEBRLw4zeyY5Sj2YdS
a4dhN7BFgvBQyqM+/E4GpAZ+e/aa3Csi+eLhgvIgKIY7rucA1MFhVhYIBKPLZ2pW
FfLlGrzPEXibfZ5uaWOuMlxmNyXLq03dPyD5JND4kg7QW4OaOmg2Le8HGLvo6eVK
tes9NuqZJn29V12lXoJ361EP4T68ubjRztz2YmUNfwOZO5OLBoPJlV9iEgLbcL/t
nbqTtmNvFpJ66p6OFG58yOUeXjRSVS9V5Moo1PpF+JqbvXTzmWlpDDVvcs0Wg+uT
jHfjzyIFfkYoSkezRbP6OPwq6YkqLw6xwOetV/QEEQqUqE6Zz7yHp5fZ5ehZJt0a
aGT6rGxYRoPB0FvzP9xBPxpDjKZQaDISQ0OUbm6MD3BK2EFbQ2GwDCZPCKsRRDEK
md+koHPo74penmOfTHYKODrn8WXTHddjSN77ojKhOH0GYKAgX2Wa574kCieQ/mVl
DbUnoIxUlKpomePi1hgI2kQAXM0XqKW5+6fDJW0KcTrBp4O3pcFwThpuHK2C4CZl
vobRlv0u39bYHuOxTn6I
=CW/s
-----END PGP SIGNATURE-----

--mjcl9URQg9JcUc2RT2PeXXUeVF2N5nq4S--