Fwd: Re: Request for feedback on Signature Assistant

[Olivier JG]

Accidently didn't send to list.

-------- Original Message --------
Subject: 	Re: Request for feedback on Signature Assistant
Date: 	Mon, 01 Nov 2010 20:49:49 +0800
From: 	Olivier JG <olivier.jg at gmail.com>
To: 	Milian Wolff <mail at milianw.de>



This is unfortunately not that simple, let me go through what you said...

On 11/01/2010 07:10 PM, Milian Wolff wrote:
>  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
Not the Declaration but a struct with the basic info taken from it.
And just to be clear, it doesn't store the old edition of the function
you are editing, but the current edition of the other side.
>  - 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?
Doing the diff is exactly the problem. You have exactly two bits of
information:
1. The current state of the other side
2. The current state of the side you are editing.
The current sig assist works with this, but it's magic.

Diff this:
editing side (declaration): void func(int a, int c, int b);
other side (definition): void class::func(int a, int b, int c) { }

Did b and c switch places for the sake of beauty (or maybe to add a
default arg to b), or did they actually get renamed?
And that's just the beginning. The declaration doesn't have to have
names, or they could be different names. And that's not to talk about
changing types. Or Adding arguments. Or removing arguments.

>  For the other way around:
>
>  - some local var gets renamed, we know it's old identifier
Key issue #1: no we don't, we know what the other side calls it, no
reason for them to be the same.
Key issue #2: I could write it so that I do know its old identifier,
same as I did in the RenameAssistant, because I can track the range.
However, I cannot track the type's range, this is the problem.
>  - bubble up the context until we find a function context parent with a
>  parameter declaration of the "old" identifier
Identifiers are not guaranteed to exist or be the same. The only way to
know which arg matches which is matching the type and position. If I
can't track the type, I can't track the argument.
>  =>   save that too, start rename assistant, start signature assistant for saved
>  function
>
>  isn't that feasable and not-really-hard-to-do?
In the best possible case, being able to get any range I want and store
any declaration I wish, this won't be easy. Note that multiple arguments
can be added, removed or replaced(!) in a single edit, and the best that
can be done then is not offer anything that breaks stuff.

-Olivier JG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101101/0be796ab/attachment.html>