About FunctionDeclaration and ClassFunctionDeclaration

[David Nolden]

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