Proposal for a UUID package

From: Date: Fri, 29 Oct 2010 15:59:23 +0000
Subject: Proposal for a UUID package
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-53880@lists.php.net to get a copy of this message
Hello all, I started to make some code about a package for generating UUIDs that I would like to publish in PEAR and I have some question about that. I know that there is a PECL package doing that ( http://pecl.php.net/package/uuid ) but here I propose a pure php-sided package. I know that in some way the php uniquid() function do the trick, but I propose to completely follow the RFC. My first question is: is it of interest? In more details my proposal consists of: * An interface representing a Uuid. There are methods to get it as string, URN and raw (big)int because it is database friendly. This interface is implemented by different classes for the different variants. Right now I only plan to do the variant in RFC4122. * An interface for a Uuid generator. It has two methods: creating a new Uuid and getting the variant of generated Uuids. There is one extending abstract class for the variant given in the RFC, which is itself declined into one abstract class for each Uuid version. These ones are defined because they expose an algorithm to subclasses (for example for version 1: getLock, getNodeId, getClockSequence, ...). Finally we have the real classes implementing the algorithms. Right now I have plans to implement at least one solution for each version. I also want to implement a generator using the PECL extension. * A factory for the real use. This factory is configurable by providing the string name of the Uuid generator (it uses Reflexion to instantiate it) and possibly parameters. The generator instance is stored internally, there is a method to retrieve it and a shorthand to directly get a new Uuid. * At loading the script looks if the PECL is present and if so configures the factory to use it. Otherwise it uses one of the other generators is provided. * The user can still change the generator used, and even provides its own one, at runtime by calling the configuration method on the factory. So now my second question: do you think this implementation is acceptable, or do you see any possible improvement? Technically speaking is make use of the gmp library to handle all my large integers. My third question: does this cause any problem (interoperability, ...)? My current implementation try to follow pear coding style, but still needs a some work, and I wait for your answers before finishing it. I think I have the time to maintain it in the future. Thanks for reading Mathieu

« previous php.pear.dev (#53880) next »