NewPascal plans, Generics.Collections and FPC trunk

[marcov]

2) Sorry, but this is the reason, why some people think, that C++ is better, than Pascal, and that at some point, when you become professional enough - you should migrate to C++. I've analysed it many times - there are no other way to complete my task in Pascal, other than so called class composition - i.e. storing references to ancestor classes right inside descendant classes and declaring 3-4 levels of wrapper methods.

It is a very rare pattern, and usually there are other ways around it (in the class composition) to work around it. One could argue needing it is a code smell.

There are maybe a few cases left, specially on the lowest level in runtime libraries

Specially for such lowlevel simple cases, in theory devirtualization and other global optimization techniques might reduce overheads of workarounds by inlining the delegated interface methods in the main class, eliminating the reference

[Mr.Madguy]

It is a very rare pattern, and usually there are other ways around it (in the class composition) to work around it. One could argue needing it is a code smell.

There are maybe a few cases left, specially on the lowest level in runtime libraries

Specially for such lowlevel simple cases, in theory devirtualization and other global optimization techniques might reduce overheads of workarounds by inlining the delegated interface methods in the main class, eliminating the reference

I don't think, that container pattern is rare.

[Thaddy]

friends are not container patterns - the opposite is true - and are easily implemented with interfaces.
It should also be possible with a pure abstract and sealed pascal intermediate advanced record and a type cast, btw. That's how I initially got Steinberg's ASIO working on FPC and Delphi:
Make sure first VMT entry you are interested in start at offset 0. The FPC default entries have negative offsets, just like Delphi.

BTW it is enlightening to google for Bjarne Soustrup and "friends" in C++......(While E. Coyote)

[hnb]

Make sure first VMT entry you are interested in start at offset 0. The FPC default entries have negative offsets, just like Delphi.

probably this is not true anymore, from RTL :

Code: Pascal  [Select][+][-]

1.        { These were negative value's, but are now positive, else classes
2.          couldn't be used with shared linking which copies only all data from
3.          the .global directive and not the data before the directive (PFV) }  

[Thaddy]

Maciej, as far as I know it is when the record contains only abstract methods and is sealed too, the typecast on an external reference will work.
I will test, though. Would be bad if it does not work anymore, because it was a way to avoid flattening C++ classes....And these assume a VMT starting at 0.

Anyway friend patterns are not container patterns and easily solved with interfaces.

[hnb]

3) Assignment operator isn't supported, as I know. You can't declare "operator Implicit(A:TMyType):TMyType" - compiler would complain about it.

with NewPascal you can use management operators: AddRef and Copy instead of "operator Implicit(A:TMyType):TMyType", see:

https://github.com/newpascal/freepascal/blob/330aad68b600d7748fd337afa9aad93a4ee35464/tests/test/tmoperator8.pp

[Thaddy]

Indeed, and that was a very valuable contribution. But it is also in trunk.

[Mr.Madguy]

friends are not container patterns - the opposite is true - and are easily implemented with interfaces.
It should also be possible with a pure abstract and sealed pascal intermediate advanced record and a type cast, btw. That's how I initially got Steinberg's ASIO working on FPC and Delphi:
Make sure first VMT entry you are interested in start at offset 0. The FPC entries have negative offsets, just like Delphi.

Yeah, I know, that it's possible to be implemented via interfaces and 2nd level of abstraction in my project actually uses them. And I know, that I can use some crazy methods, like constructing classes/interfaces at runtime. I can also generate binary code at runtime, yeah. But all this solutions are clunky, don't you think? I just want to write clear and consistent code, like this:

Code: C++  [Select][+][-]

1. template <class TKey, class TValue>
2. struct TPair {
3.   TKey Key;
4.   TValue Value;
5. };
6.  
7. template <class T>
8. class TAbstractList {
9. };
10.  
11. //Implementation
12.  
13. template <class T>
14. class TList:virtual TAbstractList {
15. };
16.  
17. //Pair list - reuses List features, but adds some pair-specific ones
18.  
19. template <class TKey, class TValue>
20. class TAbstractPairList:virtual TAbstractList<TPair<TKey, TValue>> {
21. };
22.  
23. //Please note! Implementation REUSES TList code
24.  
25. template <class TKey, class TValue>
26. class TPair:virtual TList<TPair<TKey, TValue>>, virtual TAbstractPairList<TKey, TValue> {
27. };
28.  
29. template <class T>
30. class TAbstractSet {
31. };
32.  
33. //Implementation - REUSES TList code!
34.  
35. template <class T>
36. class TSet:virtual TList<T>, virtual TAbstractSet<T> {
37. };
38.  
39. template <class TKey, class TValue>
40. class TAbstractDictionary:virtual TAbstractSet<TPair<TKey, TValue>> {
41. };
42.  
43. //Implementation - REUSES TPairList, TSet and TList!
44.  
45. template <class TKey, class TValue>
46. class TDictionary:virtual TPairList<TKey, TValue>, virtual TSet<TPair<TKey, TValue>>, virtual TAbstractDictionary<TKey, TValue> {
47. }
48.  

And slight modification would allow us to cast set to list and dictionary to any other class.

Code: C++  [Select][+][-]

1. template <class T>
2. class TAbstractSet:virtual TAbstractList<T> {
3. };
4.  
5. template <class TKey, class TValue>
6. class TAbstractDictionary:virtual TAbstractPairList<TKey, TValue>, virtual TAbstractSet<TPair<TKey, TValue>> {
7. };
8.  

[hnb]

Indeed, and that was a very valuable contribution. But it is also in trunk.

yes it is in trunk but for how long? The future of this feature is not safe in FPC trunk (I guess it can be removed). This is because:

* without FastRTTI it has some side effects
* Management Operators are more valuable with default field/property feature for smart pointers. Without this feature MO operators are not much usable
* my work for default field/properties is totally blocked in trunk, I am banned in core so it can't be discussed in normal way
* Management operators are in progress. There is idea for two more operators for safe/fast work with threads

without FastRTTI, without extensions and without "default field" feature, MO functionality should be removed from trunk because it brings more negatives than gains.

[Mr.Madguy]

with NewPascal you can use management operators: AddRef and Copy instead of "operator Implicit(A:TMyType):TMyType", see:

https://github.com/newpascal/freepascal/blob/330aad68b600d7748fd337afa9aad93a4ee35464/tests/test/tmoperator8.pp

Yeah, that looks like what I actually want. But how about automated try...finally...end feature, interfaces have?

[hnb]

Yeah, that looks like what I actually want. But how about automated try...finally...end feature, interfaces have?

Finalize operator is called even when exception occurs, so you don't need to use "try finally end" for records with Management Operators.

[Mr.Madguy]

Finalize operator is called even when exception occurs, so you don't need to use "try finally end" for records with Management Operators.

Ok. Only multiple inheritance left and I'll be happy.

[Thaddy]

Multiple inheritance would make me freeze the last build before it was introduced and never look forward again.
It is the single baddest thing to - out of many - have, as Bjarne Soustrup agrees, in C++.
And we have multiple inheritance through interfaces, which is less likely to cause stupid non-maintainable code.

Look at it in the light of "with" syntax: it causes mayhem, because people start to use it...Never trust programmers...
They tend to forget or not know about scope...
Multiple inheritance - C++ style - is BAD!. Just like "with" is. Multiple inheritance interface style is sane, but we have that already.

There is no sane way to resolve name clashes using C++ other than scoping explicitly. Which renders it useless. If I see it during code reviews, I insist on having that code changed/removed.
[edit]
Note Maciej's management operators (and Sven, he made some contributions if I am not mistaken) work very, very well and I use them a lot in new code.

[soerensen3]

How about allowing this for generics:

Code: Pascal  [Select][+][-]

1.   TMakeSpatial < T: TObject > = class ( T )
2.       //[..]
3.       procedure RotateAroundAxis( Axis: TVec3; Angle: Single );
4.       property Position: TVec3 read FPosition write FPosition;
5.       property Rotation: TVec3 read FRotation write FRotation;
6.   end;
7.  
8.   TMakeRenderable < T: TObject > = class ( T )
9.       //[..]
10.       procedure Render;
11.       property Visible: Boolean read FVisible write FVisible;
12.   end;
13.  
14.  
15.   TSomeClass = class( TMakeSpatial < TObject > )
16.   end;
17.  
18.   TAnotherClass = class( TMakeSpatial < TMakeRenderable < TObject > > )
19.   end;
20.  
21.   TThirdClass = class( TMakeRenderable< TObject >);
22.  

I think it's perfectly understandable, doesn't require many changes in the compiler (I think so because it is even possible but does not work in some cases). It does not require real multiple inheritance but it has all the benefits of it. Even "is" and "as" operators work in combination with interfaces. I've used this for some time in my engine and removed it because it did not work in all cases and code completion does not support it. I think it is more a hack than a feature at the moment.

[hnb]

Note Maciej's management operators (and Sven, he made some contributions if I am not mistaken) work very, very well and I use them a lot in new code.

It was consulted with Jonas, Florian and Sven. Management Operators functionality was made by me. IIRC when final patch was ready, Sven was against the management operators and he did not want them in trunk.