In the 10.2A OO docs there's a section entitled:
STATIC type-name syntax and naming conflicts
The following situations involving STATIC type-name syntax can result in name conflicts that cause unexpected behavior or compiler errors:
My question is - why can't the compiler tell the difference between
static-class-name:method-name()
and
a db field with the same name as the class
?
One would think this would be a fundemental capability of the parser to figure out that the ":" means this is a class reference.
no?
static-class-name:method-name()
and
a db field with the same name as the class
ttAllMyHandles.BufferHandle:BUFFER-FIELD("someField")
is a counter example. The current model is probably a good thing, for backward compatibility/historical precendence usually wins out for don't-break-existing-working-code reasons, although you can strongly argue either way and have a good case.
-- peter
And, as Peter's example illustrates, using names like ttMyTempTable, inSomeInteger, chSomeCharacter, etc., i.e., with type prefixes, tends to eliminate the problem because the name is made unique by the prefix.
One would think this would be a fundemental capability of the parser to figure out that the ":" means this is a class reference.
Well, only Progress knows. I've had similar discussions with them in the past. The consensus was often, that the compiler is already very complex to maintain, because the language is that complex (in the number of options).
What drives me nuts, is that I have to quote .NET generic types or arrays - for the same reason.
You get used to it