Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100396
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 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>
 <2cc94622-7f64-93af-c248-e82647e8053e@fleshgrinder.com>
 <1a596f98-cc6d-4e9f-b51a-3905fe1b0d97@heigl.org>
Message-ID: <9b5570db-dd1f-f2db-3e04-57f53bc06462@fleshgrinder.com>
Date: Tue, 5 Sep 2017 22:04:33 +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: <1a596f98-cc6d-4e9f-b51a-3905fe1b0d97@heigl.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="mxAfGVvWnKtv5ckvLAIETEkM97b69Jfwc"
Subject: Re: [PHP-DEV] [VOTE] UUID
From: php@fleshgrinder.com (Fleshgrinder)

--mxAfGVvWnKtv5ckvLAIETEkM97b69Jfwc
Content-Type: multipart/mixed; boundary="mDhJhOegiHvWe0H53428AuW57HGDSqxU6";
 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: <9b5570db-dd1f-f2db-3e04-57f53bc06462@fleshgrinder.com>
Subject: Re: [PHP-DEV] [VOTE] UUID
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>

--mDhJhOegiHvWe0H53428AuW57HGDSqxU6
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/5/2017 9:32 PM, Andreas Heigl wrote:
> I'm well aware of that and perhaps I didn't express myself as clear as =
I
> should have.
>=20
> 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 method=
s
> 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
>=20
> 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.
>=20
> The alternative would be to implement a UUIDInterface that exposes the
> relevant methods and that would be implemented by \UUID itself.
>=20
> But that's just my 0.02=E2=82=AC
>=20
> Cheers
>=20
> Andreas
>=20

OK, now I understand it better. I would argue that if we really find
something existential that should be added, we should add it to the UUID
class itself.

See, the problem with allowing extension is that we have a real BC
issue. All your arguments are well received and correct, but the open a
can of worms that is impossible to close. Keeping it final ensures that
this cannot happen, ever. We can continue to refine without breaking
anyone. I think it also was Ocramius who released a nice article about
"final first", but there are probably many from the Java world.

Btw. the interface does not really make sense. Interfaces are for
polymorphism, in other words, if there are different implementations of
the same thing that should be usable interchangeably. This is definitely
not the case with UUIDs, the algorithm is set in stone. Don't forget
that you can instantiate any kind of UUID with the `fromBinary` method,
so you can easily generate different UUIDs on your own and still use the
built-in class; no need for extension.

--=20
Richard "Fleshgrinder" Fussenegger


--mDhJhOegiHvWe0H53428AuW57HGDSqxU6--

--mxAfGVvWnKtv5ckvLAIETEkM97b69Jfwc
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

iQIcBAEBCAAGBQJZrwNRAAoJEOKkKcqFPVVrFVEQAIzGN2kZfbtOauCA77BqZc2t
WrXjL7CY79zTpFK3orcby5OuZdr1nyDsyoa1CBqgAw4Y1ct8TrmTb1LNefMF6KZv
6VS+vWbPwjnm6rBk7Fc93wMetQ2cWxHwGyA0ZSbUpgLor+LVOfmf5VHGyD3iUp7t
Ab26AFlUMQ9u9op05NuK2XM6sGWHRz70DqnM3Lfc87mQ07zt3fX3epSzbxEaAd9k
7mhP6pog8jWfPymfTLmxRQnIMN9VFipAJQ1hS62jFu79zVUkZ1LyegZwgj7vJ6D5
a/qVRfp6xpSgQW98Xk2gbDoIXOP4NfNl0b/FSIqSansAYQpAqOtKGeE2SlcGkqP4
8/GL3sGZXUD4Z22EHKm2etKvBoYYriMyPHBiI/+/03f9C4tqJOknUdZF1mIAVl+1
RSyOm1bhG33zo6VomNol+SS7Agw2kGkcy9pjqa5wLUwXQc4KhVlBKorIMvkLjrKv
ctAjjf58VWP2JtRM75gW7utBN+EO7XG3Zoc7GgX7lh10Fu7s15pHIYQqOkLoECqb
w1rp2eXw8Mc/3U5wyaFvBfqB3fsAVJ2ZbahjJs4YIzE4NyhJUmAn2FcOGz6f4ntA
kZRfEJ/RcnRU+62xDOrrZ441NffSIF23gCZJckYmo4s1PPDRIg18D345o8pl5/+E
SDeneT1abUEyftYSOktH
=tB+P
-----END PGP SIGNATURE-----

--mxAfGVvWnKtv5ckvLAIETEkM97b69Jfwc--