Just read the following in today's KB update...

CLASS Test:

    CONSTRUCTOR PUBLIC Test():

        DEFINE VARIABLE MyVariable AS INTEGER NO-UNDO.

        OutputMethod(MyVariable).

        MESSAGE MyVariable
            VIEW-AS ALERT-BOX.

    END CONSTRUCTOR.
    
    METHOD PRIVATE VOID OutputMethod(OUTPUT MyParam AS INTEGER):

        ASSIGN MyParam = 42.

    END METHOD.

END CLASS.

I find it very upsetting that this compiles and changes the value of the caller...

me too.

me too.

Hehehe, definitively not the first time a bug gets promoted to a feature :)

I can imagine the use case that started all this... someone had a internal entry with an input parameter then though he need to send some updates back so turn the param to input-ouput. The only think that he had to do was to update every line where the code was called but somehow managed to convince TS it might be a good idea to just do the upgrade silently and let him keep on calling with the default direction (input), if you specify input when calling the method the compiler will catch that though.

Please Progress, put this one on the "Strict compile" list, or simply remove this feature and make it optional, as this is nothing more than a bug...

I fully agree that this is a serious bug that has to be removed!!

We seldom use "Input" with parameters, as this is defined to be the default and therefore using "input" or not has to be treated the same!!

Lieven,

I wrote that KB article and it is my understanding that this is not going to change.  The reason for this is that method calls utilize code written for user defined functions and this functionality has been part of the product ever since UDFs were introduced.  You (and we) may not like the way it works (the developer and I don't) but basically the horse left the barn many years ago and to change this now will break customer applications so the choice is to break applications (never a good thing) or live with what is in reality a very small thing (given that no one complained about it when using UDFs).

I must say that I am confused as to why this is such a problem for you.  If there is a single method in the class then we just 'make things work'.  If there are multiple variants of the method in the class (with varying parameter lists) then you will end up with compilation errors so it can't be that you may accidentally invoke the wrong method variant.

This is a non-issue if the code is written such that parameters always specify their mode (which is what I would expect programmers to do).

Brian

Lieven,

One more thing .. in your sample code above the method is designed to change the value of its parameter.  Your call to the method is simply doing what, logically, you would expect it to do.  Why is that so wrong?  

Yes .. I understand that from looking at the code, it is not obvious from the method call that the value will be changed but again, we are doing what you actually want done.

I would agree with adding this to a 'strict compile' option.

Brian

As noted in this thread, one of the features the Language team is investigating as a candidate for the 11.7.0 release, is the introduction of an extension to the COMPILE statement which allows the developer to specify options which customize the compilation process.  My expectation is that this feature will be in an upcoming ESAP (early software access program) for 11.70.  OpenEdge development is working on the introduction of three options:

require-full-names:  This requires that all table and field names be their full unabbreviated names as they appear in the schema. That is, this disables the compiler’s ability to implicitly resolve abbreviated names in tables.

require-field-qualifiers: This requires that all buffer references (including database tables, temp-tables, and buffers) be fully qualified. It disables the ability of the compiler to implicitly resolve the buffer to which a field reference refers.

require-full-keywords: This would disable the support for abbreviated keywords in the language

The issues / concerns noted in this thread will be added to this feature's backlog.

Thanks

Damn, looks like Brian is write on that one... not that it makes it any better but the whole thing is even documented (Parameter passing -> default mode), somehow I've always though the default mode is input but seems not to be the case so guess that disqualify us as programmers :(

Hi Brian,

[quote user="Brian K. Maher"]

Lieven,

I wrote that KB article and it is my understanding that this is not going to change.  The reason for this is that method calls utilize code written for user defined functions and this functionality has been part of the product ever since UDFs were introduced.  You (and we) may not like the way it works (the developer and I don't) but basically the horse left the barn many years ago and to change this now will break customer applications so the choice is to break applications (never a good thing) or live with what is in reality a very small thing (given that no one complained about it when using UDFs).

[/quote]

I completely agree that this can't be changed for the reasons you mention. I do however hope this could become one of the "Strict compile" options we've discussed aboutin other threads.

[quote user="Brian K. Maher"]

I must say that I am confused as to why this is such a problem for you.  If there is a single method in the class then we just 'make things work'.  If there are multiple variants of the method in the class (with varying parameter lists) then you will end up with compilation errors so it can't be that you may accidentally invoke the wrong method variant.

[/quote]

Let me just say that I think this is one of those enhancements that should never have happened. Just 'make things work' by allowing the developer to write incorrect statements (since INPUT is the default and the developer didn't specify anything else so he meant INPUT) is not the right way imho. I rather get compiles errors, than spend hours trying to figure out a bug that could have been introduced by this feature.

[quote user="Brian K. Maher"]

This is a non-issue if the code is written such that parameters always specify their mode (which is what I would expect programmers to do).

Brian

[/quote]

As said above, INPUT is the default and as such shouldn't need to be specified.

Kind regards,

Lieven

[quote user="Brian K. Maher"]

Lieven,

One more thing .. in your sample code above the method is designed to change the value of its parameter.  Your call to the method is simply doing what, logically, you would expect it to do.  Why is that so wrong?  

Yes .. I understand that from looking at the code, it is not obvious from the method call that the value will be changed but again, we are doing what you actually want done.

[/quote]

I agree, this is a stupid example. I wrote the simplest code trying to demonstrate what happens.

I could have written something that would cause unwanted effects on the caller side by not anticipating a changed value in the variable, but I didn't spend time on that.

[quote user="Brian K. Maher"]

I would agree with adding this to a 'strict compile' option.

Brian

Marian,

You can continue being a programmer.  However, you must reduce your daily intake of caffeine and junk food by one for a period of 30 days to make up for your crimes against programming.  <smile & laugh>

Brian

[quote user="Evan Bleicher"]

The issues / concerns noted in this thread will be added to this feature's backlog.

Thanks

Lieven,

I did argue with the developer that this is a bug that should be fixed (after all, I submitted the bug report <smile>) but I didn't win.  Adding this to the strict compilation list is the best we are going to get (thanks to Evan for adding it to that list).

Brian

www.urbandictionary.com/define.php