Comment by ajuc
11 years ago
It's already done in most IDEs and you probably use it :)
Ctrl+click on method invocation - did it jumped to the declaration?
Click on some method name and choose "show all invocations" or sth like that. Here you have one of the possible tree views of code.
Another tree-view of code is visible when you have code folding feature enabled.
Another one - when you debug and show subfields of some variable.
Yes, it's nice to have these additional abstractions over plain text. But these abstractions are inherently leaky, and I much prefer to work with text files than with some binary format to fix the leaks.
It's already done in most IDEs and you probably use it :)
That's a kludge. "True" form is text and the the IDEs add a layers on top. The right way is making the tree be the canonical form and leave text just as an interchange format.
But these abstractions are inherently leaky...
Inherently. That's bold and you give no justification. Anyway I like how you prove my last paragraph. It's been conventional wisdom for so long that you consider text representation as the fundamental form and using a format closer to the real structure a leaky abstraction.
The tree would just give you code-folding for free. Callgraphs, searching for references etc would still need to be recalculated by the code indexer. The only advantage is - no parsing step.
Meanwhile you would need to rewrite all the universal text-based tools from scratch specifically for your particular binary format. And this almost never happens so people are left with no way to merge files (Oracle Forms I'm looking at you).
BTW - merging and diffing files is when the abstraction often leaks, too, or at least wants to leak.
For example - when you have 2 trees with every node the same, but root node changed from <interface> to <class>. I guess your tree-based tool shows the whole tree as a difference? What about when you wrap half of the tree in <namespace>?
Textual diff would be 2 lines in both examples.
There are many possible situations, and I admit that in some tree-based approach is better, but there are many situations where you need better granularity than is possible without leaking the lower level. With text format that lower level is human-readable, and you can automerge unsafely (but concisely) and leave fixing the result to human. With binary format if you couldn't detect concise description of the change - you just show "everything was deleted and that new file was added" which isn't particulary helpful to the person that merge changes.
Can you merge word documents or databases? There's certainly market for that.
Callgraphs, searching for references etc would still need to be recalculated by the code indexer.
The what? Sorry, I really don't know what you're talking about. If you want to introduce a reference, logical thing to do is checking it in the same moment.
The only advantage is - no parsing step.
There are many more, see my other reply to icebraining.
About tools, you seem to give more importance to diff than to write programs with a more powerful environment. I can't agree. Also I don't think creating a suitable diff for trees is a hard problem. I just need to convince Linus of the idea and he will write one in a couple of days :-)
3 replies →
The key to merging trees is that your editor generates the diff on the fly as you write—your editor's undo/redo stack and your version control system become one and the same. Every time you add, move, copy, switch out, or delete a node, the editor notes the operation on your delta log. When you push your code externally, you're really just shipping the log.
With these semantic deltas, merging should be highly unambiguous and automatable, even in degenerate cases.
2 replies →
That's a kludge. "True" form is text and the the IDEs add a layers on top.
Why is text the "true" form? What's the difference between an IDE that uses text as the "true" form and one which uses a tree as the "true" form but uses text as the UI and serialization format?
Why is text the "true" form?
It shouldn't. It's what the current IDEs do.
The difference is that the program is currently written as text and passed to the compiler, that expects text. The IDEs make a parallel construction to offer some goodies to the programmer.
How I think it should be: the IDE would actually do the syntax checking and reference resolving work, so any program you have written is in fact pre-validated.
There would be performance enhancements, but that's not the only advantage. One example that comes quickly to mind is applying macros, writing GUI generation wizards based on DB schema and in general applying "DRY".
3 replies →