On Di., 5. Sep. 2017, 21:32 Andreas Heigl <andr...@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:andr...@heigl.org N 50°22'59.5" E 08°23'58" | > | http://andreas.heigl.org http://hei.gl/wiFKy7 | > +---------------------------------------------------------------------+ > | http://hei.gl/root-ca | > +---------------------------------------------------------------------+ > >
