Re: [PHP-DEV] [VOTE] UUID

This is only part of a thread. view whole thread
  100390
September 5, 2017 17:29 Fleshgrinder <php@fleshgrinder.com>
--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--
  100394
September 5, 2017 19:32 Andreas Heigl <andreas@heigl.org>
--aB9F09eXLVqqgrdxHmJWdBBQN2LhpxQBV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 implementa= tion.
>> >> 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_ver= ify"=E2=80=A6
>> >=20 > Hi Andreas! >=20 > Thanks for your feedback. >=20 > 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.
>=20 > 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
>=20 > 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 --=20 ,,, (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 | +---------------------------------------------------------------------+ --aB9F09eXLVqqgrdxHmJWdBBQN2LhpxQBV--
  100396
September 5, 2017 20:04 Fleshgrinder <php@fleshgrinder.com>
--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--
  100402
September 6, 2017 07:19 me@kelunik.com (Niklas Keller)
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 integration > >> 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 good > >> 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. > >> > >> 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 but > >> not extend it. So userland code can not typehint for the UUID-class when > >> special features are necessary that would need extending the class. And > >> 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"… > >> > > > > 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, we > > 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€ > > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | > | http://andreas.heigl.org http://hei.gl/wiFKy7 | > +---------------------------------------------------------------------+ > | http://hei.gl/root-ca | > +---------------------------------------------------------------------+ > >