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 [thread overview]
Message-ID: <3A63BCF7.1060608@k-3d.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0101161314220.23569-100000@moshpit.cygnus.com>
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
next prev parent reply other threads:[~2001-01-15 19:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-06 7:57 h j
2001-01-15 16:32 ` Mo DeJong
2001-01-15 18:16 ` Ben Elliston
2001-01-15 18:20 ` Mo DeJong
2001-01-15 19:16 ` Timothy M. Shead [this message]
2001-01-15 19:36 ` Crazy Ideas Was: " Ian Roxborough
2001-01-16 1:07 dave.banham
2001-01-17 9:30 ` Eray Ozkural (exa)
2001-01-16 8:24 Kirby, Dave
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A63BCF7.1060608@k-3d.com \
--to=tshead@k-3d.com \
--cc=egcs@cygnus.com \
--cc=sourcenav@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).