> -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > 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 [mailto:[EMAIL PROTECTED] > >>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: > > http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/package- > summary.ht > > 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 sites. 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 Generators)? (Culled from http://thesaurus.reference.com/search?r=2&q=sequential) > > > > > > >>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]: o.a.c.id.uuid, > 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
