On 5/25/2017 12:34 PM, Michał Brzuchalski wrote: > 2017-05-25 12:14 GMT+02:00 Nikita Popov <nikita....@gmail.com>: >> I'm wondering if just adding a uuid_v4_create() function (directly >> returning a UUID string) might not cover the 95% use case here. My general >> impression is that that's what people are usually interested in -- parsing >> UUIDs etc. seems to be a rather niche concern. >> >> Nikita >> > > I've looked on `Ramsey\Uuid` usages in `prooph/event-store`, > `prooph/common` and also > `broadway/broadway` with `broadway/uuid-generator` - most of use cases is > generating > UUID and dumping to string and to bytes. But there is sometimes used > UuidInterface not mentioning > this interface functions, creating Uuid object guarantees the object is > valid UUID which is not true while > using string dumped UUID generated using functions like `uuid_v4_create()` > there's need for > additional check if given string really is a valid UUID - which is not > needed while using specialised object. >
That is exactly the reason for the class. It is not to be super fancy OO to be cool. It is for type safety. Strings in PHP are random bytes, UUIDs are random bytes, how can you distinguish them? With a UUID type-hint. :) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
