QML/JS aliases vs. imports

[Denis Steckelmacher]

On 07/10/2014 02:28 PM, Milian Wolff wrote:
> Yes, only import what you need. If you only want to import everything, always,
> just to get code completion, you do it wrong imo. Instead, you can offer,
> during code-completion, all "public" items from other files in the same
> folder. In the DUChainBuilder, when you encounter a use of an unknown
> declaration, you ask the persistent symbol table for a file that declares it.
> Or just go over the files in the same folder. Then, if you find something
> viable, add an import for that file to the topducontext you are currently
> parsing and connect the use.
>
> This is what PHP is doing for years and works quite nicely. Spamming the
> DUChain in the way you do will easily lead to extremely large caches and may
> also degrade performance quite a bit. With the above, you only pay for things
> you use. And the extra cycles during code completion are OK as well, imo. If
> it turns out to be problematic, we could/should think about sharing some code
> for the special index that PHP uses to speed up its code completion.

Sometimes, strange things can happen. I was writing an in-depth reply to 
your message, but as I was proof-reading my email, I found all the 
solutions I was asking for.

So, I'll play with the persistent symbol table. I think that this plan 
may be simple enough and do the job:

* QML module imports ("import QtQuick 2.2") already use 
addImportedParentContext
* I remove everything related to the automatic import of files in the 
same directory. When ExpressionVisitor encounters an unknown identifier, 
it uses the persistent symbol table to resolve it. This way, 
DeclarationBuilder, UseBuilder and the code-completion all work (they 
all rely on ExpressionVisitor to find the declaration of an expression). 
Is the persistent symbol table fast enough for this?
* Javascript file imports and directory imports get reworked and use 
addImportedParentContext. I don't think there will be any circular 
dependency between several Javascript files or directories.

The last point can be built on top of the first one (so, very quick to 
do and with a minimal impact on the codebase). The second point involves 
the removing of tens of not-very-elegant lines from DeclarationBuilder, 
and the addition of (I hope) a dozen lines in ExpressionVisitor. I'm 
happy, I may be able to actually remove lines from the QML/JS plugin :D!

So, thanks for this discussion!
Denis