Immutable Types

Sven Brauch svenbrauch at googlemail.com
Sun Jun 26 20:28:05 UTC 2011


Hi there!

I've recently being thinking about a DUChain feature for supporting
types which could change over time. The problematic case is this: You
set some declarations type to an expression of which you do not *yet*
know the type, but might know it later; for example, a variable "B" is
assigned to a function argument "A" of unknown type. Later, the
function in question is called and from the call a possible type for
the argument can be guessed. The python plugin does now update the
type of "A" to that type. However, there's currently no way to chain
that change to "B"; another pass would be needed for that.

I've been thinking about how to solve that problem, and I was thinking
about something like immutable types. Those could be created in case a
declaration whose type may be changed later is encountered, and for
every use of such a type, a "client" would be registered for the
expression in question to update the type of that expression. As soon
as you change the immutable type, it would invoke all its clients and
allow them to do their stuff. Such a client would usually consist of a
node to visit with the expression visitor, and a declaration for which
the type should be updated. Apart from that special behaviour when
changing the type, such an immutable type would behave like a normal
abstractType.
Of course, any type that depends on an expression which contains an
ImmutableType would need to be an ImmutableType, too, leading to ...
most types being Immutable, actually.

I created some example code which explains the idea in more detail here:
                             http://paste.kde.org/88297/

What do you think about that? Does it have any obvious logic mistakes
(I'm not sure whether that can work at all)? Do you think it will work
performance-wise? Is it possible to implement it without rewriting
half of the DUChain? Can the type-system handle so many different
types?

Greetings,
Sven




More information about the KDevelop-devel mailing list