Hi Phil, Phil Steitz wrote:
> On 1/17/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: >> Stephen Colebourne wrote on Monday, January 16, 2006 11:13 PM: >>> >> > Jörg Schaible wrote: >> >> The release plan is available now: >> >> http://wiki.apache.org/jakarta-commons/id/1.0ReleasePlan > > Looks good, though we may actually want to keep > PrefixXXXGeneratorIdentifiers. See below. >> > >> > > "Refactor PrefixXXXGeneratorIdentifier implementations" >> > This should be done with great care. id generation is very performance >> > and sync sensitive in many systems. >> >> I am sure, Phil will take care of it, if he starts refactoring. But >> basically there is not much >difference by just decorating an arbitrary >> StringIdentifierGenerator and prefixing the >resulting id compared to the >> current implementations - and the >AbstractStringIdentifierGenerator >> could implement a protected nextStringBufferIdentifier >method. Talking >> about transformation is another issue though ... > > I have started working on this. What I had in mind was just a simple > facility for creating composite identifiers created by concatenating > results of an array of generators. This does add overhead for the > prefix identifiers, so we may actually want to keep these. Well, then why do we have special ones for 3 of the StringIdentifierGenerators, but not for the other 2 and why we also do not support postfix. Hint: In one of my last projects, we had even an enhanced UUID i.e. UUID with an postfix. > Synchronization is a separate issue. I will commit some code this > weekend to look at. AFAICS all critical points have already been addressed. >> > > "Introduce a Wrappable interface for serial generators >> > that may wrap" >> > Why. What _real_ benefit does it give. This isn't a nice pretty OO >> > library - its a basic toolkit. >> >> Basically in an IoC environment an IdentifierGenerator is just configured >> and the application has then an easy way to determin by the type of the >> generator, if it is wrappable and may request or set the flag. Another >> issue is, that we unify the API of the functionality (and have to >> document it only once). But I feel not strong about it. > > I am +0 on this. So we should just make a decision about it. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
