On Thu, 2 Jan 2003, Ola Berg wrote:
> This is a FAQ (or FFB - Frequently Fought Battle): > > I don't know you guys, but personally I think the scope of lang is clear: Your view of [lang] seems spot on to me. > .... > Now that we all know this, let us identify the scope of [lang]. > .... > So, what problem domain does [lang] apply to? Well, given that it handles > primitive types, it handles things you want to do to objects of any domain, > and it handles basic java language elements, I would conclude that it belongs > in the domain of java programming in general, as opposed to java programming > in astrophysics or writing games or web apps in java. > > Is this a broad scope? Yes, if you think of a scope as a problem domain and > observes that the classes can be used in any problem domain. No, if you > consider the fact that a class or mechanism is only within scope for [lang] > if it actually is suitable for any problem domain (or at least many problem > domains). This is a criterion that narrows the number of candidates > dramatically. > > Left unattended, [lang] could (but shouldn't) swell into the monolithic > catch-all jar of 300 Megs that none of us want to download and install (or > distribute or manage). It could be easy to add feature after feature to for > instance o.a.c.lang.math until we have something that calculates the distance > to Shangri-La. +1. When org.apache.commons.lang.math reaches this stage, it ought to be org.apache.commons.math [and tbh, I don't think any of the current committers spend enough time in numerical analysis in Java to be able to do that math properly. I know I don't, and my degree was 3 years of nothing but maths]. > So how should we, members of the list, who watch over [lang] prevent that > from happen? By focusing on the scope, on the problem domain. The key words > are "any java program", "any basic language element", "regardless of > implementation" and the like. It isn't enough if a math professor claims that > he uses this FrobnitzCalculation object in all his programs, it is good if me > and you and Random J. Hacker also can see use cases for it in our web-apps or > game applets or whatever. +1. I think you've described the meme perfectly. > There are several answers to this question. > > One reasonable sized jar is easier to handle (not the best argument, I know, > but still valid in RealLife(tm)). > > Dependencies within [lang] are always solved within the releases. > > One can argue that since number ranges and predicates and input validation > share the property of being basic, they are in fact not unrelated, but > related in their lowness. Some subpackages in Lang will grow too big for their commonness-booties. At that point they need to enter discussion like this to find out if it's time to leave home, or whether to make an extension project etc. ie) java.lang.Math is in [lang], but java.math.Xxx is in [math]. [functor] is already near that point, so I can see reasons for it to be in and/or out. Nothing else described in previous emails is near to leaving home [I reckon]. > First, the things in [lang] are normally simple, so they mature quickly. > Hence there are less demands for frequent releases. Good point. Some of it gets rocket-sciencey [to me] due to class-loaders and stuff, but generally the code is simple. > Despite my bald statements on what is and what isn't above, remember that > this as usual are about two cents of worth from a simple and common non > committer, and maybe reflects more of what I think that [lang] should be than > what it is in the eyes of the maintainers Correct me if I am wrong, or > comment on it if you have the time. You've contributed a lot to Lang (and should be a committer probably). Your opinions have complete weight I think. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
