L
Lieven De Foor
Guest
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
Continue reading...
Continue reading...