arphaman added a comment.
In https://reviews.llvm.org/D38985#906893, @sammccall wrote:
> Thanks, this looks a bunch simpler.
>
> I have a question about the direction here: AFAICS there's various efforts in
> the refactoring infrastructure to allow consumers of the Refactor libs (e.g.
> clang-refactor, clangd, XCode?) to operate without knowing the details of the
> refactorings.
>
> One example is the treating the identifying `Name` of a rule as data, instead
> of referring to a subclass directly. Another is the way options are
> communicated via `OptionsVisitor` and `Requirement`s etc, where they could be
> more directly expressed as members of a `Rule`-specific struct or parameters
> to a function.
>
> An interface that truly decouples N refactorings from M consumers has
> scalability advantages, but there are some things that cut against it:
>
> - It tends to add complexity/indirection, which can slow down contributors,
> mask bugs, and makes certain features (ones that don't fit into the existing
> framework) hard to add.
> - If the generic interfaces aren't enough we pierce them, resulting in both
> coupling *and* complexity. e.g. Clangd really needs control over how
> refactorings are exposed: which ones are visible under what names, how the
> JSON-RPC messages are structured. (Because its protocol isn't really an
> implementation detail under our control, we need to be able to adapt
> to/influence editors and evolution of the LSP standard).
Good point. I agree, it would be good to have a regular refactoring-specific
interface that can be used by clangd and provide a more generic abstraction at
another layer. However, I think that Clangd will still benefit from a generic
editor interface because not all refactorings will have special protocol
support in LSP.
I've updated the patch and tried an approach that's somewhat similar to the
proposed one.
Please take a look!
> What's the biggest value we get out of the generic interface? Whose life
> would get harder if refactorings had this strawman interface/concept?
>
> template<typename Options, typename Result>
> class Refactoring {
> bool available(RefactoringContext&, const Options&) = 0;
> Error invoke(RefactoringContext&, const Options&, RefactoringConsumer&)
> = 0;
> }
>
>
> @klimek may have thoughts here.
Repository:
rL LLVM
https://reviews.llvm.org/D38985
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
