commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [uid]llang] Adding refactored [lang] identifiers to [uid]
Date Sat, 27 Dec 2003 22:29:38 GMT
Thanks, Gary! See interspersed.

Gary Gregory wrote:
>>-----Original Message-----
>>From: Phil Steitz []
>>Sent: Saturday, December 27, 2003 09:07
>>To: Jakarta Commons Developers List
>>Subject: [uid]llang] Adding refactored [lang] identifiers to [uid]
>>I am about ready to commit a more or less "rfbar" (refactored beyond all
>>recognition) version of the [lang] Identifier stuff into [uid].  Before I
>>commit anything, I want to get some feedback on the design and naming
>>choices.  Here is what I have in mind (and code, more or less ;)
>>1. Keep the [lang] IdentifierFactory interface, but rename it
>>"IdentifierSequence."  This is partly because I don't want to deal with
>>names ending in "FactoryFactory" (see below), partly because I see these
>>things as sequence generators, not class factories.
> I do not have much of a problem with an IdentifierFactoryFactory but I am
> not fond of IdentifierSequence because of the implied semantics of what a
> sequence is, which might not be appropriate for some ids. 

Well, to me what these identifier-generator thingies do is produce 
sequences of identifiers, similarly to the way that a random number 
generator generates a pseudo-random sequence of numbers.  That's why I 
chose "Sequence" over "Factory."  I also thought seriously about leaving 
off the suffix entirely -- i.e. doing like Random does and just calling 
the base interface "Identifier," but I was afraid that that would not 
capture the sequence-generating behaviour.

> (Perhaps JAXP kind of class names would work, food for thought:
> IdentifierBuilder and IdentifierBuilderFactory. (Reference:
> ml) Of course, "builder" is not really appropriate in this case but offers a
> good starting point.)

I like the "Builder" name.  Probably better than "Sequence".

> A gang-of-four synonym for "Abstract Factory" is "Kit", so you could have an
> IdentifierKit producing IdentifierFactory's. 
> IdentifierFactory idFactory = IdentifierKit.newUniqueLongFactory(...); 
> I kinda like that one.
>>2. Change the Long and String subinterfaces to abstract classes named
>>"AbstractLongIdentifierSequence", "AbstractStringIdentifierSequence."
>>This is so they can include some default behavior.  I also
>>added methods (with default implementations) to return the maximum and
>>minimum lengths (resp. values) of generated identifiers, as this is a
>>common request from users (wanting to know how long the ids can be).
>>3. Define an abstract IdentifierSequenceFactory class to enable pluggable
>>IdentifierSequence implementations of various kinds (including all of
>>those in [lang] and uuids as well). This class has a static newInstance()
>>method that uses [discovery] to locate a concrete factory, defaulting to
>>DefaultIdentifierSequenceFactory, which creates instances of the
>>IdentifierSequences provided with [uid].  The setup here is more or less
>>copied from the distribution framework in [math] (thanks, Brent!).
> I am cautiously, timidly, waiving a tiny little red flag ;-) This seems
> quite complicated for a first cut. Would an application really need this
> kind of decoupling and pluggability? The answer I "sometimes" I suppose.

Wave away.  That's why I posted before committing anything :-)

> We should make sure that we can run code and examples /without/ any config
> files or [discovery] jars being of around or logging taking place. Perhaps a
> separate IdentifierKit class could be created to hold all of this fancy
> stuff ;-) The IdentifierKit would remain the basic guy... I am just looking
> for a simpler picture/code path for simple cases :-)

The [discover] jar would be necessary, but no config would be required, 
since things would default.  I think that the behaviour that you are 
ascribing to IdentifierKit is what the refactored IdentifierUtils would 
provide.  Could be we could combine these; but I wanted to keep the static 
stuff out of the "Kit" and to support declarative specification of 
identifier implementations.  With some more/better thinking, this could 
probably all be done in the "Kit."  Remember that it will be better for 
users if we provide (access to) singletons, since many/most identifier 
generators are stateful.

>>4. Create packages called "sequential," "random," and "uuid" to house the
>>IdentifierSequence implementations and farm out the inner class
>>implementations from [lang]'s IdentifierUtils into these packages.  I see
>>all but the "StringSessionIdentifier" from [lang] as "sequential", the
>>former being "random."  I also envision a "secure" package down the road
>>to house "secure random" and signed/verifiable identifiers.
> This is why I am not fond of the "Sequence" in the class name, .sequential
> and .random sound opposite but would both implement something "Sequence"?
> That does not sound quite right to my ears, IMHO, that is.

You have now convinced me that "Sequence" has to go ;)

> Perhaps a better name for .sequencial would be .list, or .sequence, I am not
> sure.

By "sequential" I meant identifiers that go in some sort of predictable 
sequence (like [lang]'s StringNumeric, StringAlphanumeric, and Long 
identifiers). I don't think that "list" captures that.

>>5. Hack away all but the static methods and "handy singleton storage"
>>from [lang]'s IdentifierUtils and keep this as a convenience class.
> We should see what the code pile ends up looking like, it does not sound
> like such a class should any longer be needed.

Except that it provides static singleton instances for the "Builders" (or 
whatever we decide to call them :)

>>6. Create a test framework for uid implementations.
>>One question that I have regards supporting pluggable strategies within
>>the (as yet unwritten) uuid implementation. I want to make sure that the
>>structure above will support this in a natural way.  One approach would be
>>to add parameters that code strategy choices to
>>IdentifierSequenceFactory's uuidSequence method (similar to the way e.g.
>>"wrap" works in IdentifierUtils' factory methods).  Another way would be
>>to have DefaultIdentifierSequenceFactory delegate to a proper uuid
>>sequence factory.  I guess the framework will support either approach, so
>>this decision does not have to be made immediately; but I would appreciate
>>any thoughts/concerns that others have on this.
> Hmm... I am concerned about what sounds like two levels of plugability. We
> should wait and see what it all looks like ;-) I see the main level of
> pluggability at the IdentifierKit level, you can ask it for different kinds
> of Id Factories. Are you saying that for UUID Factories, there is yet
> another level of plugability, seems quite a load! ;-) I think we need to
> look at example client code to get a better idea. That will make this
> discussion easier I think by flushing/fleshing out design from client code
> patterns. Let's get something working and then see if refactorings come out
> naturally.

I think that I agree with you.  It's probably better to keep to one level.
>>Comments?  Suggestions?  Volunteers?
> (A) IdentifierKit producing IdentifierFactory's
> The more I "talk" (write) about these classes, the less comfortable I am
> with Id "Sequences" producing Id Factory's.


> I propose an IdentifierKit
> producing IdentifierFactory's, where an IdentifierFactory produces Ids.

Or "IdentifierFactory" producing "IdentifierBuilders."

> (B) Id vs. Identifier
> Using "Id" instead of "Identifier" in names. IdKit producing IdFactory's.
> There is nothing lost when using "Id", it is a very common abbreviation.

I prefer the whole word.

> (C) The project/package name [uid] vs. [id]
> The project/package name is [uid] but we always talk in terms of
> "Identifers" and it does not feel like "Unique" is always in mind. Perhaps I
> am not used to the project yet but a sign is that we are considering a .uuid
> subpackage name, which seems very odd when you look at it this way:
> o.a.c.uid.uuid. Uh? ;-)

Yes. I could go either way on this one. I generally do have uniqueness in 
mind when thinking about the "Builders," though it will almost never be 

> Which is why I'd like to propose [id] instead of [uid]:, etc.
> This leaves the room for all sorts of future factories, producing more or
> less unique Ids depending on the context.
> Thanks for reading this far!

And thank *you* for reading this far!

I will make the naming changes suggested above (holding off on the uid -> 
id change for now) and commit (unless you or others feel strongly about 
killing the abstract factory in 3. immediately) with some tests that 
illustrate client code and we can take it from there.  Thanks again for 
the feedback.


> Gary
>>I have all but 5. and 6. implemented now.  I will likely finish these
>>today.  I will commit something (so we have something concrete to talk
>>about) tomorrow or Mon. incorporating whatever feedback I get between now
>>and then.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message