[news.eclipse.technology.ldt] Re: Beyond textual represenations...

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

(Sorry for the delay...)

I think you missed the basic point of there being a single representation 
for any number of views. Having a clean and simple single representation 
allows your tools to present and work with the data however they want 
without worrying about "what the code looks like."

One of my favorite examples is code format. Regardless if you use tabs or 
spaces, where you put your { }, additional explanatory parens in 
expressions, etc, the AST is the same.

The editor could worry about editing a data structure rather than a text 
file. This would allow each developer to edit in the format they like (tabs 
or spaces) without causing diffs to the stored representation.

Editors could add 'extra' syntax. For example, the editor could do

    foo(x = 42, y = 10)

when calling a method so you can see which parm is which, or maybe collapse 
javabean properties to

  PROPERTY: String x, read/write/bound

I'm sure much of this can be done with eclipse, but some changes behind the 
scenes may help, and looking at Roedy's excellent SCID page can give some 
goals to work towards.

Later,
-- Scott





Other tools could represent or view code based on the representation without 
having to constantly re-parse the code. For example, flow graphs, 
refactorings, etc.

As for using external tools, there's always an export/import path available. 
External tool users are likely scripters so adding export and import to 
their scripts should only be noise.

The comment about storing as XML is interesting. I personally think it's way 
verbose, but that would mitigate the "proprietary-ness" of the stored 
representation.