Peculiar resolution

Posted by Thomas Mercer-Hursh on 01-Oct-2015 16:05

I have a code fragment which goes like this:

        define buffer bfCompileSubUnit for CompileSubUnit.
        create bfCompileSubUnit.
            bfCompileSubUnit.chID = guid
            bfCompileSubUnit.chName = ""
            bfCompileSubUnit.chType = "ProgramRoot"
            bfCompileSubUnit.chCompileUnitID = chCompileUnitID

The *intention* was that chCompileUnitID was a variable defined at the class level which would get assigned from the current CompileUnit.chID when that record was created.  However, it turned out in this particular program that not only was this assignment not done, but the variable was never defined.  So, why did this compile?   From the XREF, it appears that it resolved chCompileUnitID as the field in CompileSubUnit, i.e., assigning a field to itself.

Seems peculiar.

All Replies

Posted by Mike Fechner on 01-Oct-2015 16:10

It's the same as

FIND FIRST Customer.

ASSIGN CustNum = CustNum .

In doubt, when no local variable is found, the ABL assumes unqualified (with a buffer Name) field name references.

That's why, I use type prefixes on variables - but not on DB fields.

It's been like that for at least 26 years.

Posted by Thomas Mercer-Hursh on 02-Oct-2015 16:56

I suppose the issue in my naming scheme, which is derived from Peter Headland's, is that compile unit level variables have no prefix.  E.g., method scope variables are mch, but class level are just ch.  If compile unit level variables also had a prefix, then this wouldn't happen.  Bit of a bugger to change now, though, although I guess this is a good reason to do so.

Posted by Mike Fechner on 02-Oct-2015 17:00

To me you have just proven that you should rethink your DB field namings:

Either with a prefix like f for field or no prefix at all.

bfCompileSubUnit.fchName or


but never


Posted by Thomas Mercer-Hursh on 03-Oct-2015 09:29

And, why, exactly, do you find that compelling?  Seems to me, that, if anything, the column name in the DB is the base and everything else is derivative so the derivative should have the prefix.  One of the pluses of the prefix in the dictionary is greatly reducing the likelihood of a conflict with a reserved word in a future version.  There was a period a number of years ago where I was prefixing the table name with tb for that reason, but I seem to have fallen away from that.  The more I think about it, the idea of a prefix which means scope is compile unit makes a lot of sense ... it just isn't what Peter did lo those many years ago.

Posted by Jurjen Dijkstra on 05-Oct-2015 03:41

I believe that good-old Prolint should catch that with rule "tablename". Actually it warns that field "chCompileUnitID" is not fully qualified with a tablename - which implies that "chCompileUnitID"  resolves to a buffer-field and not to a parameter or variable.

This thread is closed