Gary Gregory wrote:
>>-----Original Message-----
<snipping stuff from previous/>
>
>
> 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.
>
>
These are good points. It is really just a matter of convenience for
users. Since many generators will be stateful, users will want to hold
onto singletons to generate sequences. What I had in mind was to strip
[lang]'s IdentifierUtils down to instantiate a factory like so (changing
Sequence to the "winning" name -- I like "Generator" too;):
private static IdentifierSequenceFactory factory =
IdentifierSequenceFactory.newInstance();
create singletons like this:
public static final StringIdentifierSequence
STRING_NUMERIC_IDENTIFIER_SEQUENCE = factory.numericSequentialSequence();
and expose convenience generator methods like this:
public static String nextStringNumericIdentifier() {
return STRING_NUMERIC_IDENTIFIER_FACTORY.nextStringIdentifier();
}
This way, users who want to just use default impls can call
IdentifierUtils.nextXXX() to generate sequences without worrying about
creating instances of generators. Subsequent calls will maintain the
sequence, which is being managed behind the scenes by the Singleton.
I agree, however, with your reservations about providing this kind of
thing and if you feel strongly, I will not include the IdentifierUtils
class. Then users will always have to do the first two steps above
themselves and maintain their own generator references.
Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|