The main problem about your idea is that it is based on changing the
actual types in the duchain, which cannot work stably when multiple
threads do the same thing at the same time, and is not really elegant.

In C++, there exists basically the same problem with
template-functions/classes. There, it is solved by cloning
declarations/contexts dependent on the actual instantiation types, and
using DelayedType for the actual types, which is then resolved by the
expression-parser on-demand. This solution only works if all types are
correctly annottated though.

In python the problem is a bit more complicated, and cannot really be
solved properly, because the types can depend on a huge mount of
different context parameters.

I would try to solve the whole thing alone within the type-system, by
creating something like a "ContextDependentType" (similar to
DelayedType), which can be "refined" by giving it some
context-parameters, for example the types of certain
function-parameters. This would require a new set of types, one for
each operation that transforms the context-dependent types (for
example nThItem, namedMember, etc.), which can then be evaluated in a
specific context.

Example:

def some_func(p1, p2):
   p1  | TYPE: ContextDependentDeclarationType ( some_func::p1 )
   p2  | TYPE: ContextDependentDeclarationType ( some_func::p2 )
   added = p1 + p2  | TYPE: ContextDependentOperatorType ( "+",
ContextDependentDeclarationType ( some_func::p2 ),
ContextDependentDeclarationType ( some_func::p1 ) )
   blaMember = added.bla | TYPE: ContextDependentMemberType ( "bla",
ContextDependentOperatorType ( "+", ContextDependentDeclarationType (
some_func::p2 ), ContextDependentDeclarationType ( some_func::p1 ) ) )
   someItem = blaMember[0] | Type: ContextDependentIndexType ( 0, ... )

And so on.

Then, define a instantiation-context, for example: { "some_func::p1" :
string, "some_func::p2" : MyClass }

And each context-dependent type needs a function "AbstractType::Ptr
evaluate(InstantiationContext iContext, DUContext* context)" which
evaluates the type dependent on the context.

This might blow the type-system up indefinitely, but might work, and
would be the right way to do it.

For now though, I would concentrate on making the python support work
as good as possible with explicit type annotation, which is the only
thing that can _really_ work reliably.

Greetings, David

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel