About FunctionDeclaration and ClassFunctionDeclaration

Sven Brauch svenbrauch at googlemail.com
Thu Mar 8 23:42:18 UTC 2012


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?




More information about the KDevelop-devel mailing list