Proposal for a UUID package
| From: | Mathieu Bruyen | 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