commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [id] Review before 1.0 (Summary)
Date Fri, 20 Jan 2006 21:19:35 GMT
Hi Phil,

Phil Steitz wrote:

> On 1/17/06, Jörg Schaible <> wrote:
>> Stephen Colebourne wrote on Monday, January 16, 2006 11:13 PM:
>> > Jörg Schaible wrote:
>> >> The release plan is available now:
>> >>
> 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:
For additional commands, e-mail:

View raw message