It would be nice to have a single tree of classes that are GNU
*extensions* to Java. I don't care what the names are, we could call them
gnuj.* or something if you want. The point is, keep our public extensions
and the basic supporting classes together. The classes we plan to support
in future releases, versus those we don't plan to support. org.gnu vs. gnu,
or gnu vs. gnuj, whatever the heck you want to call it.
Paul was talking about making Classpath better than the standard Java
libraries, and one way to do that is to add more public supported classes.
We need a place for those, and a distinction between those and the throwaway
classes no one should rely on.
I just don't want to bicker yet about which classes to support as
standard and which ones not to. The naming convention is a good thing to
bicker about right now, before release.
--John Keiser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
> M. Renn
> Sent: Sunday, October 25, 1998 12:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: gnu vs. org.gnu: a possible useful distinction
>
>
> John Keiser wrote:
> > org.gnu.* becomes the repository for miscellaneous extra
> classes that just
> > help out the main, useful ones. These classes could be
> deprecated and go
> > away at any time, just like com.sun classes.
>
> Despite your suggestion, I'll go ahead and bicker. There is no reason to
> use "org.gnu" ever. It is just extra typing. The GNU project has already
> adopted "gnu." as standard. Anybody who names a non-GNU class as "gnu."
> deserves to lose. We have to date been putting support classes
> analogous to
> com.sun inside "gnu.java" to indicate that these are support
> classes for the
> GNU java runtime. Remember, other people are writing code and putting it
> "gnu" as well. This gives us a protected namespace and reduces typing
> overhead.
>
> --
> Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
>
>
