### Author Topic: Annoying issues in Object Pascal - what are those?  (Read 11505 times)

#### ASerge

• Hero Member
• Posts: 705
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #30 on: February 14, 2017, 01:24:54 pm »
@Lupp
See example:
Code: Pascal  [Select]
1. type
2.   T1 = array of Integer;
3.   T2 = array of array [1..100] of Integer;
4.   T3 = array of array of Integer;
5.   T4 = array [1..100] of array of Integer;
6.   T5 = array [1..10, 5..20, 3..40] of array [1..6] of array of Integer;
7. var
8.   A1: T1;
9.   A2: T2;
10.   A3: T3;
11.   A4: T4;
12.   A5: T5;
13.   N: Integer;
14. begin
15.   N := 8;
16.   SetLength(A1, N);
17.   A1[1] := 1;
18.   SetLength(A2, N);
19.   A2[2, 10] := 2;
20.   SetLength(A3, N, 4);
21.   A3[5, 3] := 3;
22.   SetLength(A4[88], N + 2);
23.   A4[88, N + 1] := 4;
24.   SetLength(A5[1, 6, 22, 4], N - 2);
25.   A5[1, 6, 22, 4, N - 3] := 5;
26. end;
All memory free at procedure end;

#### bytebites

• Full Member
• Posts: 138
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #31 on: February 14, 2017, 01:53:31 pm »
Concerning the syntax (and semantics) of alternatives, whether complete: if ... then ... else  or incomplete: if ... then

I prefer to understand begin  end as a pair of parentheses for the purpose of making one item out of many  like ( )  [ ]  do in different contexts. C, C++ actually use the curly brackets for the case of statements where Pascal uses reserved words for better distinctness (and out of old tradition) .

Unpaired parentheses are a plague!

If there will be changes in this field one day I would prefer to abandon these wry pairs:    record   end  and   case   end.
Are there more?
At least
class end
try except/finally end

#### Lupp

• New member
• Posts: 30
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #32 on: February 14, 2017, 03:11:42 pm »
@ASerge: It's not completely clear to me if you wanted to tell me "You are wrong!", and if so with which one of my theses.

What I see is a demonstration of how you suggest to get dynamic arrays of many dimensions. These are shaped to a size calculated from a varianble only with respect to one (the last one by index position) dimension.

I cannot see a demonstration about how
- to get a satisfying surrogate for array[1..m, 1..n] of Double
= to write a procedure for, say, the multiplication of two arrays callable like MatMult(Left, Right, RowsLeft, CommonSize, ColsRight, Result)
= (Editing) ...or, even much better, without the three sizing parameters.
This is: Without the need of mapping pairs of indices to 1D.

What did I miss?
« Last Edit: February 14, 2017, 04:45:54 pm by Lupp »

#### jacmoe

• Sr. Member
• Posts: 259
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #33 on: February 14, 2017, 03:15:09 pm »
Coming from C/C++ and having a good grasp on Python and Javascript, while being a PHP developer also, I happen to really appreciate begin - end pairs.

To me, begin / end pairs - especially when written in all lowercase - sort of blends into the background, but are so much better in explaining block levels than whitespace (Python) or braces (most other languages).

Yes, it is verbose, but I like that verbosity because it reads well.
It is much more difficult to read out loud C++ code.
In FPC, a class constructor is called 'constructor', and abstract methods are called 'abstract'.
Yes, it's wordy, but you sort of need to learn to love it. It is Pascal, after all.
more signal - less noise

#### ASerge

• Hero Member
• Posts: 705
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #34 on: February 15, 2017, 01:56:44 am »
- to get a satisfying surrogate for array[1..m, 1..n] of Double
= to write a procedure for, say, the multiplication of two arrays callable like MatMult(Left, Right, RowsLeft, CommonSize, ColsRight, Result)
= (Editing) ...or, even much better, without the three sizing parameters.
This?
Code: Pascal  [Select]
1. program Project1;
2.
3. {\$APPTYPE CONSOLE}
4.
5. type
6.   T2DArray = array of array of Double;
7.
8. function Init2DArray(M, N: Integer): T2DArray;
9. begin
10.   SetLength(Result, M, N);
11. end;
12.
13. function Multiply2DArray(const A, B: T2DArray): T2DArray;
14. var
15.   i, k: Integer;
16. begin
17.   SetLength(Result, Length(A), Length(A[0]));
18.   for i := 0 to High(A) do
19.     for k := 0 to High(A[0]) do
20.       Result[i, k] := A[i, k] * B[i, k];
21. end;
22.
23. procedure Print2DArray(const A: T2DArray);
24. var
25.   i, k: Integer;
26. begin
27.   for i := 0 to High(A) do
28.   begin
29.     for k := 0 to High(A[0]) do
30.       Write(A[i, k]:5:2, '  ');
31.     Writeln;
32.   end;
33.   Writeln;
34. end;
35.
36. var
37.   A, B, C: T2DArray;
38. begin
39.   A := Init2DArray(2, 3);
40.   B := Init2DArray(2, 3);
41.   A[0, 0] := 1; A[0, 1] := 2; A[0, 2] := 3;
42.   A[1, 0] := 4; A[1, 1] := 5; A[1, 2] := 6;
43.   B[0, 0] := 7; B[0, 1] := 8; B[0, 2] := 9;
44.   B[1, 0] := 10; B[1, 1] := 11; B[1, 2] := 12;
45.   C := Multiply2DArray(A, B);
46.   Print2DArray(A);
47.   Print2DArray(B);
48.   Print2DArray(C);
50. end.

#### ASerge

• Hero Member
• Posts: 705
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #35 on: February 15, 2017, 02:35:34 am »
The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
1. try
2.   ...
3. except
4.   ...
5. finally
6.   ...
7. end;
Not very useful. Often used option
Code: Pascal  [Select]
1. try
2.   Alloc;
3.   try
4.     DoSome;
5.   finally
6.     Free;
7.   end;
8. except
9.   HandleErrors;
10. end;
not covered by this pattern.
Ideologically different design. Try finally to conserve resources, but try except for error handling.

#### lazjump

• Jr. Member
• Posts: 61
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #36 on: February 15, 2017, 03:32:29 am »
I think the opposite.

Years ago I read the source of VCL and as long as I remember they almost always had try...except inside try...finally. This is the most often usage. Not the opposite.

try...except...finally...end would be very useful and used often.

The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
1. try
2.   ...
3. except
4.   ...
5. finally
6.   ...
7. end;
Not very useful. Often used option
Code: Pascal  [Select]
1. try
2.   Alloc;
3.   try
4.     DoSome;
5.   finally
6.     Free;
7.   end;
8. except
9.   HandleErrors;
10. end;
not covered by this pattern.
Ideologically different design. Try finally to conserve resources, but try except for error handling.
I thought Delphi was expensive until I learned the price of ExtJS

#### Phil

• Hero Member
• Posts: 2569
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #37 on: February 15, 2017, 04:21:24 am »
The only annoying thing for me is that something like this is not yet possible:
Code: Pascal  [Select]
1. try
2.   ...
3. except
4.   ...
5. finally
6.   ...
7. end;
Not very useful.

Other languages have a "unified" try/except/finally. That doesn't preclude the use of nested try/finally and try/except as in the 2nd example.

https://www.python.org/dev/peps/pep-0341/

https://msdn.microsoft.com/en-us/library/dszsf989.aspx

In Pascal and other languages, try/finally and try/except (or catch) are really two different things, but confusingly introduced by the same try keyword. try/finally is about doing things that have to be done to clean up properly, completely unrelated to whether an exception occurred. try/except is only about handling the unexpected exception condition.

The Swift language does it in a way that keeps the two concepts separate: do-catch, like try/except. And defer, which can be used any number of places in a code block. Any time resources have been allocated, you can immediately use defer to specify the clean up. One obvious advantage is that the cleanup code is physically close to the resource allocation. In the other languages, the cleanup code in finally is often many lines away from where the resources were allocated. See example at bottom of page here:

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html

#### ASerge

• Hero Member
• Posts: 705
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #38 on: February 15, 2017, 05:00:27 am »
Years ago I read the source of VCL and as long as I remember they almost always had try...except inside try...finally. This is the most often usage. Not the opposite.
try...except...finally...end would be very useful and used often.
I quickly try this code:
Code: Pascal  [Select]
1. procedure ParseFile(const FileName: string; Result: TStrings);
2. var
3.   Source, Sorted: TStringList;
4.   i, Level, GroupCount: Integer;
5.   Line, TryLine, Group: string;
6. begin
7.   Sorted := TStringList.Create;
8.   try
9.     Sorted.Sorted := True;
10.     Sorted.Duplicates := dupAccept;
11.     Source := TStringList.Create;
12.     try
14.       Level := 0;
15.       TryLine := '';
16.       for i := 0 to Source.Count - 1 do
17.       begin
18.         Line := Source[i];
19.         if AnsiEndsText('try', Line) then
20.         begin
21.           Inc(Level);
22.           TryLine := TryLine + 'try ';
23.         end;
24.         if AnsiEndsText('finally', Line) then
25.         begin
26.           Dec(Level);
27.           TryLine := TryLine + 'finally ';
28.           if Level <= 0 then
29.           begin
30.             Sorted.Append(Trim(TryLine));
31.             TryLine := '';
32.             Level := 0;
33.           end;
34.         end;
35.         if AnsiEndsText('except', Line) then
36.         begin
37.           Dec(Level);
38.           TryLine := TryLine + 'except ';
39.           if Level <= 0 then
40.           begin
41.             Sorted.Append(Trim(TryLine));
42.             TryLine := '';
43.             Level := 0;
44.           end;
45.         end;
46.       end;
47.     finally
48.       Source.Free;
49.     end;
50.     Group := '';
51.     GroupCount := 0;
52.     for i := 0 to Sorted.Count - 1 do
53.     begin
54.       Line := Sorted[i];
55.       if Group <> Line then
56.       begin
57.         if Group <> '' then
58.           Result.Append(Format('%-3d: %s', [GroupCount, Group]));
59.         Group := Line;
60.         GroupCount := 1;
61.       end
62.       else
63.         Inc(GroupCount);
64.     end;
65.     if GroupCount > 0 then
66.       Result.Append(Format('%-3d: %s', [GroupCount, Group]));
67.   finally
68.     Sorted.Free;
69.   end;
70. end;
71.
72. procedure TForm1.Button1Click(Sender: TObject);
73. begin
74.   Memo1.Clear;
75.   ParseFile('c:\Program Files (x86)\Borland\Delphi7\Source\Rtl\Common\Classes.pas',
76.     Memo1.Lines);
77. end;
And get result:
Code: Pascal  [Select]
1. 12 : try except
2. 84 : try finally
3. 2  : try try except except
4. 2  : try try except finally
5. 1  : try try finally except
6. 7  : try try finally finally
7. 1  : try try try finally finally except
8. 1  : try try try finally finally finally
9. 1  : try try try try except finally finally finally
10. 1  : try try try try finally finally finally finally
11. 1  : try try try try finally finally try except except finally
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately

• Hero Member
• Posts: 5801
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #39 on: February 15, 2017, 07:15:36 am »
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately
Hm. then they should be used more often, because the finally protects also resources from within an exception block.
I use it all the time. I thought most real programmers would ..
Because you can really recover from the exception gracefully and without memory leaks.
It's even best practice.
« Last Edit: February 15, 2017, 07:17:17 am by Thaddy »
recommends {\$macro on}{\$define Silly:=ObjFpc}

#### jacmoe

• Sr. Member
• Posts: 259
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #40 on: February 15, 2017, 08:47:08 pm »
I think it is really unfortunate that try except and try finally are separate.

Coming from other languages, it is not very intuitive.

That is an annoying issue in my book.
Easy to work around, but annoying none the less IMO.

Edit:
Thinking about it, having a try except nested in a try finally could be a more explicit way of expressing how try except finally actually works..
« Last Edit: February 15, 2017, 08:54:09 pm by jacmoe »
more signal - less noise

#### bee

• Sr. Member
• Posts: 320
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #41 on: February 17, 2017, 03:14:28 am »
My own complain about modern Pascal limitations:

1. try…except and try…finally being separated. Too many words to type while it can be simplified as try…except…finally.

2. Dedicated block for vars and consts is a limitation when you need to create consts on the fly or in the middle of a program, such as:
Code: Pascal  [Select]
1. const x = function(a)

3. Incompatible type for similar data type, such as:
Code: Pascal  [Select]
1. type
2.   aoi: array of integer;
3.
4. function a(i: array of integer);
5.

4. More helper on basic types, such as for array, so newcomers don't need to dig the docs.

5. More complex data type such as tuples and dictionaries.

I think modern Pascal can learn from Swift which I think a new programming language that brings old features with better syntaxes.
-Bee-

A long time pascal lover.

• Hero Member
• Posts: 5801
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #42 on: February 17, 2017, 05:02:38 am »
Well dictionaries are both in rtl-generics and in FGL (where it's called map, same thing, though).
recommends {\$macro on}{\$define Silly:=ObjFpc}

#### Zoran

• Hero Member
• Posts: 1186
##### Re: Annoying issues in Object Pascal - what are those?
« Reply #43 on: February 17, 2017, 10:01:50 am »
Line 4, line 9 and may be line 11 it's not used often. In most cases, they are used separately
Hm. then they should be used more often, because the finally protects also resources from within an exception block.
I use it all the time. I thought most real programmers would ..
Because you can really recover from the exception gracefully and without memory leaks.
It's even best practice.

I wonder if there is a real difference between these two procedures (because, in Proc2, DoCleanup is executed, whether or not DoSomething raises exception, same as in Proc1, right?):

Code: Pascal  [Select]
1. procedure Proc1;
2. begin
3.   try
4.     try
5.       DoSomething;
6.     except
7.       HandleExceptions;
8.     end;
9.   finally
10.     DoCleanup;
11.   end;
12. end;
13.

and

Code: Pascal  [Select]
1. procedure Proc2;
2. begin
3.   try
4.     DoSomething;
5.   except
6.     HandleExceptions;
7.   end;
8.   DoCleanup;
9. end;
10.

EDIT:
Ah, I was too quick, I see what you mean:
because the finally protects also resources from within an exception block.
« Last Edit: February 17, 2017, 10:05:29 am by Zoran »