Re: Crazy Ideas Was: Re: Java hiccups

[Ian Roxborough <irox@redhat.com>]

Mmmmmmmm, yes, something I've heard about a few times.
The biggest benefit would be  NO MORE CODING STANDARDS!
Yippee, no more whining about this coding standard verse
that one.  You just set any coding standard you want in
your editor and nobody will ever care.

And many great advantages for doing code refactoring as well.

A more realistic way would be to store source code in
XML format, which then could be read into either a xref and symbol
database or into a compiler (or into an editor of course).
But when you try to deal with file based languages, Java is bad
for this (path = package name), as is C due to the use of static, you
start to have some problems.

Ian.

"Timothy M. Shead" wrote:
> 
> 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