RE: Crazy Ideas Was: Re: Java hiccups

["Kirby, Dave" <dkirby@orchestream.com>]

Not such a crazy idea.  Take a look at IBM's VisualAge for Java, which does
exactly that (i.e. keep the code in a repository instead of text files).  It
is based on VisualAge for Smalltalk, and of course Smalltalk has done things
this way from the beginning. 

I haven't used VA myself, since I am developing in C++, but I know lots of
Java developers swear by it, especially in the XP community.  You can even
get a refactoring browser for it.

For a discussion on its merits & some links, see
http://www.c2.com/cgi/wiki?VisualAge

Regards,

	Dave Kirby



> -----Original Message-----
> From: Timothy M. Shead [ mailto:tshead@k-3d.com ]
> Sent: 16 January 2001 03:16
> Cc: sourcenav@sourceware.cygnus.com
> Subject: Crazy Ideas Was: Re: Java hiccups
> 
> 
> 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
> 
>