Re: Proposal for a UUID package

On Fri, 2010-10-29 at 17:59 +0200, Mathieu Bruyen wrote: > Hello all, Hi Mathieu, > 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? > There's no harm in starting a proposal. I, for one, think it's a good idea and would make a good PEAR package. This sounds like a good proposal for PEAR. > 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. The interface and features you describe sound great! > * 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? If you're looking for guidance on how to implement multiple backends, I advise you to look at the HTTP_Request2 package. The way HTTP_Request2 works, it uses a default adapter class and you can set any other adapter class if you need to. This design works great for testing. > Technically speaking is make use of the gmp library to handle all my > large integers. > My third question: does this cause any problem (interoperability, ...)? > Nope, dependence on PECL libraries is allowed for PEAR packages. I think there is also a PEAR package that will use an appropriate bigint library depending on what the user has installed: http://pear.php.net/package/Math_BigInteger > 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. If you need help with the PEAR coding standards, try using the phpcs tool to validate your code. (http://pear.php.net/package/PHP_CodeSniffer/) If you need help with setting up package.xml or your directory structure, many will be glad to help out during the proposal phase. > Thanks for reading > > Mathieu > Cheers! Mike