Strongly-Typed methods within classes

[OhioJoe]

I could almost hear the gasps from "across the pond" today when I mentioned that I don't strongly-type methods within classes and the variables passed to each method. (Just so you know: I'm not quite as dumb as I sound. All of my locals and functions are typed)

In today's session about refactoring VO code (great work Stefan!) Robert explained, in response to my question, there are two reasons for strongly-typing methods within classes:

1. No need for type-checking. This will make it run faster.
2. Errors are found at compile time, rather than at run time.

Is there another reason that I missed? For example, is there a memory advantage?

I've never really worried about speed because, in the view of our customers, things run plenty fast.

I don't know exactly why I've never thought about strongly-typing methods, except that I often run into the following problem:

METHOD Joe( dPar1, cPar2, nPar3 ) CLASS CHRIS
LOCAL nReturn AS INT
DEFAULT( @cPar2, Space(0) )
DEFAULT( @nPar3, 0 )
// do stuff; calculate the return value
RETURN nReturn

This is an example of a method that is almost always called with only one parameter: a Date. But later on there's a need to implement the same method but with two or three parameters. So rather than change every line where the method is called we just create the defaults.

So my question is: Is there another way to implement a DEFAULT in a strongly-type method?

You fellows have inspired me! I will go through one of my complicated search routines, strongly type everything, and then see how it performs.

[Chris]

Hi Joe,

No grasps at all, those are very valid considerations. There are two answers to your questions, you can either use method overloading (several methods with the same name but different parameters, one calling the other when needed):

Code: Select all

METHOD Joe( dPar1 AS DATE) AS INT
RETURN SELF:Joe( dPar1, "" , 0)

METHOD Joe( dPar1 AS DATE, cPar2 AS STRING) AS INT
RETURN SELF:Joe( dPar1, cPar2 , 0)

METHOD Joe( dPar1 AS DATE, cPar2 AS STRING, nPar3 AS INT) AS INT
// ... do stuff
RETURN nReturn

or default parameters in a single method:

Code: Select all

METHOD Joe( dPar1 AS DATE, cPar2 := "" AS STRING, nPar3 := 0 AS INT) AS INT
// ... do stuff
RETURN nReturn

Even if you do not get a noticeable speed improvement by following one of the above, you are still gaining a lot in having more robust code, easier to catch coding errors etc. With the previous version of the code, it was easy to accidentally to use like Joe("string instead of date") or Joe(Today() , "" ,, 123) (note that the accidental double comma) and very possibly you would never realize this mistake if you did not happen to test this aspect of the app. With strongly typing, the compiler would had immediately told you that this is a mistake.

[OhioJoe]

Thank you, Chris. As you might expect, I've never used the method-overloading technique.

I do understand that strong typing will identify coding errors at compile time, which is better than discovering the error when the customer is trying to run payroll.

[TerryB1]

Hi Joe

There is no run-time performance advantage to be gained by Strongly Typing anything in CSharp nor in any language derived from C#.

The reason is that C# converts your code into .Net Assembler. .Net Assembler does not accept any code it does not understand, generating an exception.

Errors will be found at compile time, that is true.

Performance is largely determined by the Garbage Collector which is outside your direct control. There are only two settings that I know of Workstation and Server. Workstation is the default anyway, Server is for high throughput Servers, so you really do not need to do anything.

It is your overall program structure that will be the greatest contributor to run-time performance. A few things may help, but probably not much - to find out which check the IL code which has been generated from the C# (or derivative) in which you coded.

HTH

Terry

[SHirsch]

Hi Joe,

(in VO) another approach is a parameter object, which than can also have return values (or changed values)

Code: Select all

CLASS MyTestParameterClass
PUBLIC Value1 AS DATE
PUBLIC Value 2 AS STRING
PUBLIC Value3 AS INT

METHOD TestMethod(o as MyTestParameterClass) AS LOGIC
...
o:Value3 := -1 //here you can change the Value in the object
RETURN TRUE

With this approach we also solved the problem when we need more than one return value (which is solved in X# with tuples). The real return value is a logic indicating if everything is OK. And the 'payload' is in the MyTestParameterClass object. So you can avoid returning untyped ARRAYs.

Stefan

[Chris]

Hi Terry,

There is no run-time performance advantage to be gained by Strongly Typing anything in CSharp nor in any language derived from C#.

This is not correct. If you use untyped code in c# (by using the dynamic type), then the generated code is by far, far less efficient (calling some very large methods in the runtime that implement the late bound calls), resulting to a lot slower execution.

But indeed, this big difference in speed might not be noticeable, because often when an action takes 0.1 sec or 0.00001 ms, the user cannot feel the difference. But in code inside very tight and long loops, the difference can become very noticeable.

[robert]

Terry,
The post from Joe is about VO code moved to X#.
And since X# allows late binding and untyped code will almost always use late binding, there is a LOT of performance to be gained by strong typing, as well as better compile time checks.

Robert

[OhioJoe]

Thank you Chris, Robert, Terry and Stefan.
I should've made it clear. (Thank you, Robert.) Most of our VO applications will remain in use at least until the end of 2022. So most of the coding is done first on the "VO side" and then run through the VOExporter. In going through the old VO code, some of which was first written in Clipper (!), I've noticed some coding techniques that perhaps need to be changed for better performance in X# and beyond. So I'll start posting some of these examples and inviting comments from the brilliant members of this community (i.e. Stefan, Robert, Chris, Terry et al), hopefully for the benefit of the less-experienced. So stay tuned!

[TerryB1]

Chris / Robert

OK Understood. But I would have thought that this is all translated into what I called "Overall Program Structure"

Terry

[ic2]

Hello Joe,

The overloading solution Chris describes is possible in .Net but not in VO (you would get the error Edit contains duplicate entries).

As you may have noticed, I am often not convinced of the advantage of a newer technique. But I am convinced that strong typing should be done everywhere. From time to time we add a parameter to a widely used method/function. This then directly leads to errors for all calls to the strong typed function. Sometimes I have to add a parameter too 100+ calls. But adding a default value for the new parameter goes all very quickly in VO, only a fraction of the time I have been working on the function, usually.

I would certainly abandon the "spare parameters" programming if I were you and strong type everything. It will almost certainly save you some surprises at customers installations.

Dick