On Thu, 2 Jan 2003, Rodney Waldhoff wrote:
> Bah. I think you're being willfully obtuse about this. Possibly, but if your criteria can't be applied to everything then they are not worth applying [okay, maybe a bit too bombastic]. > The heuristic is to place types that are commonly used or changed > together, or mutually dependant on each other, into the same component. I believe this heuristic is akin to the problem of over-modeling. You see a future problem [enormous lib] and want to solve it now with a minimum of knowledge. If [lang] grows enormous, I can easily see it evolving to the structure you describe, but it does not have that size. > At the risk of getting mired in the details (and just considering the > stuff currently in lang) here's one such partitioning: > > [functor] > - containing things like: lang.functor.* > - use this when you need to: treat functions as objects [functor]'s are about 18 years old it seems. They're not quite ready to live on their own, but they want to be out there it seems. I am happy to accept functors [and the name does seem to fit the pattern [see proposal]] being their own project, but believe they will suffer to start with. They have sufficient size to overcome the slowness of being a new project. One good thing this series of discussions has shown is that there is a lot of interest in functors. Rodney, Stephen and Costin have all shown creative input in this set of mail, and the original authors of functors [Ola? Stephen? Steven? others?] obviously also have shown that input. It seems that [functor] needs to do some soul-searching. If this were a company and I were a big-cat CEO [get my shoes Smithers], then I would suggest [this is why I'm not a CEO, I think I'm meant to demand or order] that those involved start discussing the next step for functor. IFF [functor] is to see its scope widen very soon, ie) Costin's ideas, then it should form its own project. Functor with a lot of mail arguing, increase in size and a big need for good documentation will quickly become the pig in [lang]'s belly. IFF [functor] is seen to be pretty much complete, then it should go into [lang], to be promoted out IFF it is shown to grow in scope at a later date. I'm going to repeat this in another email for brevity. > [reflect] > - containing things like: lang.reflect.*, ClassUtils, etc. > - use this when you need to: manipulate objects via reflection and > introspection The code is not even finished, and I believe [lang] is still the right place for it, unless it becomes a religion that coders have to adhere to, ie) clazz. I doubt it will grow that large. > [math] > - containing things like: NumberUtils, lang.math.*, numerical analysis > functions like gcd, lcm, isPrime, getFactors, etc. > - use this when you need to: manipulate numbers or use numerical > algorithms Even with these, which is stretching the limits of math, it will be a sufficient sub-package. I believe [math] should continue [once it is even coded] to live in [lang] until such a time as it is big enough to leave home. > [datetime] > - containing things like: lang.time.* > - use this when you need to: work with dates and times Ditto as for [math], except that I think making a [time] project would be a waste of time as Stephen has already walked this road and is suitably licensed (i assume). > A more fine-grained partitioning might add: > > [string] > - containing things like: CharRange, CharSet, CharSetUtils, > RandomStringUtils, StringUtils, [WordWrapUtils], etc. > - use this when you need to: manipulate strings > > [exception] > - containing things like: lang.exception.* > - use this when you need to: manipulate Throwables, or use nested > exceptions before JDK 1.4 > > > or even: > > [assert] > - containing things like: Validate > - use this when you need to: use assertions before JDK 1.4 > > several of the remaining classes *might* logically move to an existing > component, become the kernal of new component, or simply stay in lang: > > * serialization stuff could move to [io] or to a new [serialization] I still reckon that Serializable should be in java.lang. Once [io] exists, maybe this move would be right. As [io] is unlikely to surface soon, I don't think this should happen for a long time. > * BitField could move to [collections] (i.e., as a collection of bits) or > to [math] (for things like unsigned int, unsigned short, etc) or to > [converter] (i.e., as bit-to-number conversion) I'm happy for this to happen now. Collections didn't want it when [util] was broken up before [lang] started. It's been a problem-child. > .... > The result is 4 to 7 new components, some of which might reasonably start > in the sandbox, some of which could be proposed for commons proper > immediately. All of these have stand-alone utility, strong cohesion, a > readily identifiable scope, and few if any inter-dependencies. -1 to any released code moving to the sandbox on the general principle of it. Anything that is released should either be deprecated because it has moved, or deprecated because it is redundant. Many of these ideas will be applicable this time next year I suspect, but not now. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
