About FunctionDeclaration and ClassFunctionDeclaration

[Sven Brauch]

Hi David,

yes, that already happened, we discussed that in IRC. I'm now using
the plain declaration classes again, and we changed the class browser
to display non-classmember objects too. This works fine.

Greetings,
Sven

PS: Sorry for so many emails. :)

Am 15. April 2012 14:45 schrieb David Nolden <zwabel at googlemail.com>:
> The question is, does ClassFunctionDeclaration have any members which
> you really need?
>
> The pure reason why this exists is basically to hold the additional
> "isSignal", "isSlot", "isAbstract", and "isConstructor" properties.
>
> The only thing which applies to python is "isConstructor", however you
> can also simply determine that efficiently by checking identifier ==
> __init__  using a pre-computed IndexedString, so you should probabily
> simply not use ClassFunctionDeclaration, and fix the class-browser
> instead.
>
> Greetings, David
>
> Am 8. März 2012 23:42 schrieb Sven Brauch <svenbrauch at googlemail.com>:
>> Hi,
>>
>> those two classes are causing major trouble for me currently. I
>> noticed that the class browser expects all class member functions to
>> be instances of ClassFunctionDeclaration, and other functions to be
>> FunctionDeclarations -- so I had to change that in python in order to
>> make the class browser work correctly. In the first place, this
>> doesn't make sense for python, as whether a function is a class member
>> or not is not relevant at all. If I neverthereless adopt those two
>> classes, I can't easily access properties of a function declaration!
>> For example, I used this pattern quite a few times:
>>
>>  Declaration* d = ...
>>  if ( d->isFunctionDeclaration() ) my_type =
>> static_cast<FunctionDeclaration*>(d)->type(); // or returnType, or
>> parametersCount, or... whatever
>>
>> If I have to differentiate between ClassFunctionDeclaration and
>> FunctionDeclaration now, this expands to
>>
>>  Declaration* d = ...
>>  if ( d->isFunctionDeclaration() ) {
>>    if ( FunctionDeclaration* f =
>> dynamic_cast<FunctionDeclaration*>(d) ) my_type = f->type();
>>    if ( ClassFunctionDeclaration* f =
>> dynamic_cast<ClassFunctionDeclaration*>(d) ) my_type = f->type();
>>  }
>>
>> now. This is ugly, slow, and unreadable.
>>
>> I also can't use AbstractFunctionDeclaration, it doesn't even have
>> type() or similar.
>>
>> IMO the proper way to fix this would be to have an isClassMember()
>> property in AbstractFunctionDeclaration, and have the class browser
>> check for that instead of dynamic_casting its way around [1]. Then
>> every language could do whatever it wants with that flag, and
>> ClassMemberDeclaration could have it set by default so the current
>> behaviour won't change. What do you think?
>> Alternatively, I think it would make sense to have
>> ClassFunctionDeclaration inherit FunctionDeclaration. The code of
>> ClassFunctionDeclaration duplicates FunctionDeclaration's code
>> currently anyways (for example defaultParameters(), etc). Then again,
>> I don't really understand the duchain class hierarchy well enough to
>> suggest such a change. :)
>>
>> What would you do?
>>
>> Greetings,
>> Sven
>>
>> ___________
>> [1] PS: While we're at that topic, it would be great to have a few
>> more of those functions anyways, to avoid dynamic_cast type checking.
>> For example, isClassDeclaration() would be useful for me. Is there any
>> general objection in adding such things?
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
>
> --
> David Nolden
> nolden at i6.informatik.rwth-aachen.de
> Tel.: +49 241 80 21602
> Lehrstuhl f.  Informatik 6    RWTH Aachen University, 52056 Aachen, Germany
> Human Language Technology and Pattern Recognition
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel