commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [uid]llang] Adding refactored [lang] identifiers to [uid]
Date Sat, 27 Dec 2003 23:49:40 GMT
> -----Original Message-----
> From: Phil Steitz []
> Sent: Saturday, December 27, 2003 14:30
> To: Jakarta Commons Developers List
> Subject: Re: [uid]llang] Adding refactored [lang] identifiers to [uid]
> Thanks, Gary! See interspersed.

You're most welcome, good stuff. 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.

I am not quite sure automatically providing singletons for all/most
generators is the right thing to do. I would prefer a first implementation
to leave those out in favor of having applications instantiating generators
(via the factory) and keeping track of them. I could imagine problems if two
different apps or components in the same VM choose to use a (counter
generator for example) singleton as a convenience and getting unexpected
gaps in the generated sequence due to concurrent use from different call

Here is another angle (I reserve the right to change my mind later :-):
Unless a generator must be guarded against having multiple instances
generated, a singleton should not be created. IOW, the singleton should be
used to guard against instantiations which would cause bugs, for example,
with a truly VM global counter, not a "just for convenience" singleton.

> >
> >
> >>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.

Underdstood and agreed on "list". A refinement, perhaps too early to
discuss: To my mind, sequential does not sound great as a package name.
Perhaps: .serial (The Serial Generators) or even .ordered, (The Ordered

(Culled from

> >
> >
> >>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 :)

Now I like "Generators". See above for my remarks on singletons.

> >
> >
> >>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.
> Agreed.
> > 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.

In general, I am against abbreviations, but this seems like a very common
and understood case. Not an important point now. ;-)

> >
> > (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
> "guaranteed."
> >
> > 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.
> Phil
> >
> > 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.
> >>
> >>Phil

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message