From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Timothy M. Shead" <tshead@k-3d.com>
To: egcs@cygnus.com
Cc: sourcenav@sourceware.cygnus.com
Subject: Crazy Ideas Was: Re: Java hiccups
Date: Mon, 15 Jan 2001 19:16:00 -0000
Message-id: <3A63BCF7.1060608@k-3d.com>
References: <Pine.LNX.4.31.0101161314220.23569-100000@moshpit.cygnus.com>
X-SW-Source: 2001-q1/msg00023.html

Ben Elliston wrote:

> mdejong wrote:
> 
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
> 
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
> 
> Ben

I don't know if y'all have any long-term plans for the future of SN, but 
if you do, your remark about correctly parsing correct programs reminded 
me of one of an interesting idea I ran across, one which could eliminate 
these types of problems: database source management.  The idea being 
that, instead of "storing" your program source in files, you keep it 
organized in a central database.  So you'd have tables for classes, 
methods, functions, etc. just like SN's tables, but with the bodies of 
functions/methods/etc in the database as well.  There'd never be a 
"foo.java" or "foo.cpp" - simply a set of "foo" entries in the database. 
  When it's time to compile, the database dumps the source into 
temporary file form to feed the compiler.  Advantages would include:

* Minimize parsing (at least for new projects) - since the code is going 
into the database as it's written (presumeably through some type of GUI) 
the parsing can be kept to a bare minimum (with much, much less to go 
wrong).
* More complex searches / cross references.
* Faster compile times - since the database can easily cross-reference 
function/method calls, it can avoid compiling the ones that are never used.
* Faster compiled executables - the database could perform static 
analysis of call patterns, and organize compiled code to minimize cache 
hits, something that's impractical when working with files.
* Better source management - tools like CVS track changes to text files 
at a generic level.  The database could track changes at a 
per-function/method level, and provide context for a "group" of changes 
that go together (something CVS doesn't do).  It could advise you when a 
change is going to affect other people, and advise them when you do.
* Integrated documentation - it would be possible for the database to 
help keep documentation in sync with the code - if you change an 
argument to a function/method, it can (optionally, of course!) nag you 
to update the corresponding comments.

Way out there, I know - the idea of abandoning files is scary, but worth 
looking at :)

Regards,
Timothy M. Shead