I would suggest that: ID generation fits in [lang] UUID generation does not
In other words, UUID generation with threads, timers, native code, internet specs to follow is just not [lang]-like. However a simple incrementing number/alpha id system could very well be [lang].
Interesting that's exactly what we have in the (unrealeased) /util package now ;)
Any ideas where UUID generation should go? Unless I hear a better suggestion, I will open up a sandbox project to get things started.
Phil
Stephen
----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]>
Pondering on the code we currently have for this.
[and because I was grepping for 'public interface', which I don't think Lang should have much of]
I'm not convinced that the ID stuff fits Lang's style. It has a similar style to Collections code [public interfaces, XxxUtils as a facade to implementations] which implies there is a certain amount of buy-in from the user. Collections can get away with this because the religion is the Collections API, but here we're defining a new religion for the user.
So that's another reason why it feels icky in its current place.
Even if we do include it in a later version of Lang, I'd like to move it to a package of uid or somesuch.
I'd much rather see it as a tiny commons component on its own, with a bunch of UID bits, possibly including some C code to get a mac address on common operating systems, and a clone of M$'s GUID scheme. This would depend if there are enough uid ideas out there to add to it.
DB id/sequences would be out of scope, so I might be pushing it for native id's to be in scope. There are other uid's that can be added however. One I've seen used took the time and the memory address of an object to create a unique-within-a-JVM uid.
Hen
On Thu, 18 Dec 2003, Henri Yandell wrote:
On Wed, 17 Dec 2003, Phil Steitz wrote:
__matthewHawthorne wrote:
I've taken a look at some of the uid code that is currently in
[lang].
Are we all convinced that these types of classes are definitely a
good
fit for the project? I think that they're a bit out of scope.
However,
the obvious problem is -- where else in commons to put them?
Any other [lang] committers care to weigh in on this? My HO is that
uid
generation is a useful basic language extendison and so is natural
enough
for [lang].
I'm wary of adding new packages to Lang without good cause. The uid
stuff
has come up before as code that people want access to and there are no obvious locations for it in Commons, so I'm with Matt currently. Not enamoured with it for Lang, but nowhere else to suggest it.
Hen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
