Alban Peignier wrote:
Phil Steitz wrote:

I would suggest something more along the lines of a CompositeIdentifierGenerator that could wrap an array or list of IdentifierGenerators and use these to generate "composite" ids. One example of this would be a CompositeStringIdentifierGenerator that uses concatenation to combine ids. Another strategy might be concatenate, then hash, etc.


I started with the same idea .. I created a ConstantStringIdentifierGenerator .. and it looks very similar to the functor API. Which is the difference between a ConstantStringIdentifierGenerator and a ConstantStringGenerator ?

The IdentifierGenerator could be a child of the functor.generator.Generator. In this case, all the functor API framework would be available (constant, composite, ...)


This is an interesting idea. I would be interested in others' opinions on this. Implementing functor.generator.Generator would be a signinficant change to the simple IdentifierGenerator interface, but I am open to considering it. I can see essentially three ways to go here:


1. Make IdentifierGenerator extend functor.generator.Generator
2. Follow the pattern in the FlexiMap functor example
http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/FlexiMapExample.html#84
to make generation algorithms pluggable / composable
3. Don't use functors, use inheritance instead (more or less what I was suggesting above)


Thinking about how to make 3 work, 2 is looking more and more attractive...

Any other ideas on how best to implement id composition?

Phil




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to