commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [lang] The scope of lang
Date Fri, 03 Jan 2003 01:12:42 GMT


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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message