false positives in rule "tablename" with inherited classes
Sun, 2007-02-11 01:33 — jurjen
| Project: | Prolint Issue Tracker |
| Component: | Rules |
| Category: | bug report |
| Priority: | normal |
| Assigned: | jurjen |
| Status: | closed |
Jump to:
Description
Imagine class B inherits from class A.
Class A defines a property (or variable) foo as integer.
Class B contains a statement like
foo = 17.
Prolint does not see a definition for foo in class B so it assumes that foo is a database field, and gives a "tablename" warning because the field is not qualified with a tablename.
The solution would be a two-pass parser, but that sounds like difficult.
- Login to post comments
Comments
Re: false positives in rule "tablename" with inherited classes
These things are, of course, resolved in the symbol tables built by ProRefactor, but the question is how to get Prolint to take advantage of it.
jurjen wrote:
> Imagine class B inherits from class A.
> Class A defines a property (or variable) foo as handle.
> Class B contains a statement like
> foo:some-method(params).
>
> Prolint does not see a definition for foo in class B so it assumes that
> foo is a database field, and gives a "tablename" warning because the
> field is not qualified with a tablename.
> The solution would be a two-pass parser, but that sounds like difficult.
>
>
Two pass parser
Is the issue one of needing a two pass parser or is it that ProParse needs to dynamically parse all of the classes in the reference chain as a part of parsing the current target. Yes, one might resolve it through ProRefactor symbol tables, but that would assume that the parent has been compiled and parsed in its current form. Couldn't one do that dynamically?
Re: Two pass parser
Proparse deals with superclasses, as does ProPrefactor.
Proparse makes the *super class syntax tree* available (see the Proparse user manual for the section with that name).
That's how ProRefactor gets the information it needs about the superclasses to do all its symbol resolution. Prolint could do the same. IIRC, Prolint does build a list of variables defined in the compile unit. It could do the same for variables defined in the superclass.
Proparse and ProRefactor keep in-memory caches of super class syntax trees, to avoid having to re-parse and re-examine common superclasses, similar to how the compiler works.
tamhas wrote:
> Is the issue one of needing a two pass parser or is it that ProParse
> needs to dynamically parse all of the classes in the reference chain as
> a part of parsing the current target. Yes, one might resolve it through
> ProRefactor symbol tables, but that would assume that the parent has
> been compiled and parsed in its current form. Couldn't one do that
> dynamically?
>
>
So, a ProLint task
So, if Proparse has the information available, doesn't this become "simply" a question of extending ProLint to make use of that information instead of needing to think about Prorefactor capabilities at all?
Super class syntax tree
Wow there is a lot more in Proparse than I knew. The super class syntax tree cache is new to me, looks interesting! I will give it a try.
I know ProRefactor is superior but I don't know how to get started calling it from the ABL version of Prolint.
Super class syntax tree
Yeah it works!
Works = Fixed?
Meaning you accessed the tree of the superclass and resolved the problem?
If so, quick work!
re: Works = Fixed
Thanks, yes indeed it means I have found the superclasses tree, fixed the problem and committed it to the Subversion repository as revision 303.
But it was a quick fix. It works, but I think the code does not look nice enough and can be optimized for speed too. I want to sit back and review myself later this week, but you can already export the fix from subversion if you need the fix now.
I am beginning to think there is a lot of power in Proparse that I have not touched yet.
#1
Fixed!
Committed to subversion as revision 303. The code needs a bit cleaning up, but it works.
#2