On line event 7 May 2020

[ic2]

This presentation was very interesting. Thanks again. 21 people attending is not bad but I can recommend it anyone.

I do have a question however. I see the advantage for some of the new language features but fail to see the advantage of 3.

I actually do see the advantage of the interface (for only the 2nd time I've seen an interface implemented). But I don't see the value of:

1 Foreach: advantage: there is no counter. Saves 2 lines of code, But that makes it only harder to debug (for.next we can see each element clearly using the counter). Why use Foreach then?

2 IN/OUT: I would also say that it mainly obscures what happens. By defining 2 variables, I can see in the debugger which values are returned. With In/OUT or _ ... not.

3 Also Switch - Case . Compare:

Switch AsSymbol(Name)
CASE #Chris
...
CASE #Robert
END SWITCH

to

cName:=...
DO CASE
CASE cName=="Chris"
CASE cName=="Robert"
ENCASE

Why would someone want to use the 1st notation while the 2nd is much clearer? E.g. I have to look in the Switch statement to have a vague idea what I am comparing. In the 2nd notation any CASE line tells me what I am evaluating.

And maybe one more question: can we download the code and/or the PP? I realize that you started with code 1 and modified it to use the new features to code 2, maybe put the begin and end stage in the PP presesentation?

Dick

[robert]

Dick,

Glad you liked it.

1) FOREACH can be used on anything that implements an interface that allows enumerating. So not just arrays with numeric indexes but also something that has no "ordinal" positions, like the keys or values or the key-value pairs in a dictionary.
2) _ is used for the situations where you don't care. And declaring the OUT variable inline limits its scope/visibility.
3) Speed, and compile time checks for duplicate case statements. Especially with numeric CASE labels the compiler can optimize this into a "jump table" that is much faster than the DO CASE statement.
Btw the AsSymbol() with CASE #Chris will NOT work. As far as the runtime is concerned #Chris is not a literal.

Robert

[Chris]

Dick,

I also like more the DO CASE statement, I think it is more readable. But on the other hand, DO CASE as we have it in VO is not a real statement, it's just a different way to type IF..ELSEIF..ELSE. The above sample is exactly the same as

IF cName=="Chris"
...
ELSEIF cName=="Robert"
...
ELSEIF nSomethingElse == 123 .and. Year(Today()) == 2525 // that's an extra check
...
ELSE
...
ENDIF

So DO CASE and IF are exactly the same, in both you can even test about completely different logical expressions regarding as many different variables etc. The SWITCH statement is something different, it's to be used in scenarios when testing against only one specific variable, it faster and prevents some typing errors. For example for this

SWITCH cName
CASE "Chris"
CASE "Robert"
CASE "Chris"
ENCASE

the compiler will report an error because you used the same value twice (obviously by mistake, wanted to type some other name). With DO CASE, the compiler would not even warn you about this and it would only have unexpected behavior at runtime.

Edit: Oh Robert already mentioned all that, in just 3 lines

[kevclark64]

I use FOR EACH all the time to iterate through arrays of objects. For example, I might have an invoice object that has an array of line item objects. If I wanted to set the number ordered for each line item to 0, I could do

For Each objInvoiceLine in objInvoice.lines
objInvoiceLine.ordered=0
Next

Not only does that save some lines of code, but I think the code is more readable than it would otherwise be. In my experience it's no harder to debug than using a counter.

[wriedmann]

Hi Dick,

21 people attending is not bad but I can recommend it anyone.

unfortunately I had not the time, but I will now use the YouTube registration (it is really a great thing that we can follow these sessions also later!).

And a big "Thank You" to Robert and his team for giving these sessions!

Wolfgang

[ic2]

Hello Chris, Robert,

Thanks for clarifying this. I'll make a note about the advantages of the CASE structure. For the vast majority of CASE structures in my program speed nor the chance for double used options will be an issue as these have only a few CASE statements. I do have a function DollarsToWords which converts a monetary amount to a written amount to use on USA checks. This may benefit a bit but for the rest I would prefer the more readable VO like structure (interesting that if-elseif is doing the same).

Dick

[ic2]

Hello Kevin,

I use FOR EACH all the time to iterate through arrays of objects.
....
Not only does that save some lines of code, but I think the code is more readable than it would otherwise be. In my experience it's no harder to debug than using a counter.

I do use a few FOR..EACH as well (in C# programs) but unless I missed something, it really seems harder to debug. For example:

foreach (var file in d.GetFiles("*.txt"))
{Do something}

Now suppose this would give some unexpected results and after some iterations I didn't see anything special. The next thing I would do when it were a FOR..NEXT loop is inspect the values of an array of files which I would have made before the loop. This might lead me to set breakpoints on, say, array element 20 and 35 because the file found there could cause the issue.

But in the FOR..EACH loop I have no idea what the program is processing or in which order. That's why I think FOR..EACH is harder to debug.

Dick

[robert]

Dick,
"ordered collections", like .Net arrays, XBase arrays, anything that implements IList or IList<T> (The XBase array internally is an IList<USUAL>) will be processed from top to bottom. So the order is predictable.

Robert

[mainhatten]

Robert,
for me traditional for has the benefit of modifyingbreaking on the loop counter with ease.

Did watch as I want to have played with new compiler before watching, as I then I can test and don't have to gnaw fingernails...

regards
thomas