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