|
|
|
|
|
|
by CMCDragonkai
3844 days ago
|
|
|
It can allow you to edit code faster, make changes faster, refactor faster, because rather than editing at the "text-level" abstraction, you're editing at the "code-level" abstraction. By itself it's not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor. |
|
|
I explicitly stated that I at least don't perceive editing (keystroke) speed as a limiting factor, so I'm not sure what you're trying to say. My perceptions may obviously be wrong, but I think this places the burden of proof on those claiming an improvement.
My point (or contention, if you will) is that the power gained through local refactoring like this (moving a bunch of parenthesized code around quickly) is absolutely negligable in the grand scheme of things.
> By itself it's not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor.
That's really the crux isn't it? I can only say that I haven't seen anything even close to this yet even from AST-only editors, and we've been promised it for sooooo many years.
As of now IntelliJ IDEA/Eclipse can do far more advanced refactorings at the press of a few buttons... and some of these refactorings are actually non-trivial -- as opposed to just doing a block-select and moving code.
Granted, I'm sure they have a lot of code to achieve that, but I'd wager that the actual parsing from text->AST is a very minor portion of the refactoring code. I'm pretty sure the most difficult bit of that refactoring code is the bit that guarantees that the refactor preserves semantics.
EDIT: What I'm saying is basically this: I think it's naïve to think that the AST is the big problem when doing IDE/editor-supported refactoring.