DocumentChange unpractical for signature assistant

Milian Wolff mail at milianw.de
Tue Jul 6 10:23:08 UTC 2010


Hey there,

while trying to revive the SignatureAssistant for changes in the return type, 
I saw (again, had the same problems with constness) that DocumentChange is 
totally unpractical here.

The thing is that for safety reasons we need to _exact_ old string and then 
replace that or parts of it with changes. Sounds nice. But: We don't access 
the acutal written document, hence only "guess" how the old signature looked 
like and try to replace it. Meaning:

void foo() const;

=> works (one space, then const)

void foo()\tconst
=> won't work and similar

With return type it's even harder, since one does not now whether we have:

returntype ClassName::methodName() {}

returntype SomeNamespace::ClassName::methodName() {}

returntype someTypeDef::ClassName::methodName() {}

and so forth.

The parameters at least know the range they replace (the Function context) and 
ignore the old text. For the other parts this is not possible. So what should 
we do here?

1) get AST for document and replace on that, might be slow - advantage: 
completely safe to replace

Since that's API/code wise easy to implement, I'm actually tempted to use that 
for now.

2) only get the line of the signature to change and use regex to find ranges 
for DocumentChange, i.e.:

^\s*\bOLDRETTYPE\b\s+(\w+)::FUNCNAME(.*)\s*(const)?\s*{?$

might need to handle comments though. That would be "fast", but I don't know 
what the best way is to get the string for a line in a document, considering 
it might not yet be opened. Ideas? I could just create a KateDocument but that 
might do too much, do we have something else?

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/20100706/2221cd2f/attachment.sig>


More information about the KDevelop-devel mailing list