Request for feedback on Signature Assistant

[Milian Wolff]

Olivier JG, 01.11.2010:
> On 10/31/2010 07:26 PM, David Nolden wrote:
> > IMO the signature-assistant has one big conceptual problem: It always
> > rewrites the whole function declaration line. Since in C++ there is
> > many redundant ways how to write type-names, this will always cause
> > problems.
> > 
> > I think the right way to work would be remembering a sequence of
> > edits, like for example:
> > - Replace 1st argument with ...
> > - Remove 3rd argument
> > - Remove 4th argument
> > 
> > And then replaying those changes on the other side. That way, we would
> > overwrite only those parts that were actually changed, and we might
> > also solve matching-problems in places where the argument-declaration
> > names don't match properly etc.
> > 
> > Greetings, David
> 
> This is precisely what I want to do, but the problem is accurate
> tracking, since I'm unable to get the ranges for the decls' types (and
> the const, but I'd settle for types).
> What happens, then, is a race against the clock: If the user can manage
> to change (add/remove/rename/retype) more than one parameter before the
> parse finishes, all bets are off on tracking.
> 
> It seems the best I can do without the ability to get the return type
> range, is to simply not offer anything unless there's only one change
> per parse.
> Of course, even if I could get the ranges and therefore not have to wait
> for the parse, the user could, ie, remove two arguments at once, and I
> wouldn't be able to safely offer anything, but that's an acceptable
> compromise, I think (and likely one I could account for with a little
> extra work).
> 
> As I see it, either I get those type ranges, or I have two options:
> 1. Cripple the sig assistant, but allow it to rename uses
> 2. Leave the sig assistant as is, unable to rename uses
> 
> I hope I'm overlooking something, because neither of those is
> particularly nice. We got bug 255706 within 12 hours of the rename
> assistant going in, because the signature assistant does look broken
> when it doesn't rename uses now.
> 
> How hard is it to add support to the DUChain for getting the type range
> from a declaration?

Just an idea (might be impossible to implement), but could you confirm please:

facts as I remember them:
- signature assistant stores the "old" declaration including it's parameters
- something changes, the "new" declaration gets written over the "old" 
declaration.

So, we know the "old" declaration, hence all it's parameters. Can't we diff 
old vs new and find changed declarations, then query the DUChain for those and 
start the rename assistant for them?

For the other way around:

- some local var gets renamed, we know it's old identifier
- bubble up the context until we find a function context parent with a 
parameter declaration of the "old" identifier

=> save that too, start rename assistant, start signature assistant for saved 
function

isn't that feasable and not-really-hard-to-do?

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101101/7745369a/attachment.sig>