Compilation gotchas and a request for change

yes, I agree, all this would be really useful to have. At least as an external Lint tool.

But I know what they answer about (6): "it is not possible because of Dynamic Dispatch".

While Dynamic Dispatch is almost never needed but <method not exist> is every day experience

Thanks, Sean!

Have you seen the CachéQuality linter?

... studio will complain when you try and quit a for loop with a value

QUIT from inside a loop is considered quitting a loop rather then a function, so it should always be without a value.

...but it wont complain when you try and quit with nothing on the method

According to language definition, each function can be called as a function (set x=$$function(...)) or as a routine (do function(...)). The call type can be recognized inside the function using a construct:

   quit:$quit ReturnValue quit  ; $quit=1 if called as a $$function()

Methods are compiled to functions and behave the same way.

My point was if the compiler will go as far as protecting the developer from this type of quit misshap

It seems that this kind of checkup would be difficult to implement because of variety of methods how the code could be branched depending on its call type. E.g. 

 if $quit {
     ...
     quit rc
 } else {
     ...
     quit
 }

or 

 quit:$quit rc
 ...
 ...
 quit

Of course, both code fragments demonstrate not very good coding style, but they are semantically correct. If one gets many false positives from a (hypothetical) code checker, he would likely drop it.

HI,

   The first though I have is how, for any reference outside of the routine or class being compiled, could the compiler be sure of what the routine and package mappings are going to be like at run time.  Most likely in a different environment.

   For example, even in a single instance of Cache, it is possible that for one user an argument type, argument, or return type would be correct and for another it would be incorrect.  This is because they are each using different mappings, maybe running is different namespaces, at run time.  You will notice that if you DO a non-existent routine or label in another routine it will compile, however if you call a non-existent label within the current routine you get a <NOLINE> at compile time.

    Having this only work within the current item seems to me to be of limited value.  So I am thinking that this would be a show-stopper for doing this at compile-time.  You would need something, like a 'lint', that could be run in a full test environment or even in production.

Clark

Hi,

your suggestions #2 and #3 would work against the weak typed character of the language. I.e. a method like this:

ClassMethod test() as %String { q 23}

Will work perfectly fine, no matter if you use the return value a string or integer. You can actually also return values from methods that don't define a return type at all.
As you already point out, changing any of this behaviour would likely break quite a lot of existing software, so it's not really feasible.

I think you should also consider other factor - performance. If we implemented all kinds of these checks/warnings, it would slow down the compiler, which is not the way we would like to go.