Subclassing UnsureType

Sven Brauch svenbrauch at googlemail.com
Sat Aug 6 21:58:29 UTC 2011


*push*
Does anyone know about this? It can't be too difficult, but somehow I
don't get it.

Cheers,
Sven

2011/7/31 Sven Brauch <svenbrauch at googlemail.com>:
> Hey,
>
> I'm just trying to subclass UnsureType, but I can't seem to get it to
> work. I always get weird crashes in KDevVarLengthArray (see
> http://pastebin.kde.org/104239/). (I only got it to compile when
> calling the DECLARE_LIST_MEMBER_HASH macro again, otherwise it
> wouldn't even link).
> Are there modifications necessary to the base Data class so I can
> inherit from it? I found some macros in appendedlist.h which might
> have to do with that, bit I just didn't understand it.
>
> Thanks and bye,
> Sven
>
> 2011/7/4 David Nolden <zwabel at googlemail.com>:
>> 2011/7/4 Sven Brauch <svenbrauch at googlemail.com>:
>>> Hi David,
>>>
>>> thanks for your response.
>>> I imagined this to work like this: As soon as a file is parsed, it
>>> throws all its type hints at all relevant declarations. Those stay
>>> valid until the file is re-parsed; if it's re-parsed, it just creates
>>> *new* type hints, which then are valid instead of the old ones. The
>>> old ones will then be invalidated by comparing their creation time
>>> with the current modification revision of the file, and noticing that
>>> they're old. However, I don't know how much performance that would
>>> eat.
>>>
>>> Still, your approach is probably more elegant. I'm just not entirely
>>> sure if a type-hint can be bound to a specific use in all cases; it
>>> *might* be a more complex expression. However, for the basic
>>> function-argument hints I want to implement now I think that should
>>> work.
>>> I didn't exactly understand how your example works, tough... I do not
>>> want to delete declarations if uses go away, I want to store a list of
>>> types for a declaration which are deleted if their "uses" go away. How
>>> is that to be realized with your example?
>>
>> There would need to be a version of UnsureType, where each sub-type
>> attached to the UnsureType is conditioned by a specific use.
>>
>> Greetings, David
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>




More information about the KDevelop-devel mailing list