Fwd: Re: Request for feedback on Signature Assistant

[Milian Wolff]

forwarding to list, thanks for the clarification Olivier

Olivier JG, 01.11.2010:
> 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
-- 
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/c3f0fa81/attachment.sig>