NewPascal plans, Generics.Collections and FPC trunk

[soerensen3]

Oh it's actually simple. It's just a class but when declaring the generic the parent is not yet clear but when specializing it is. This way you can not tell if a class is a descendent of any TSpatial specialization but you can still use an interface.
With interfaces alone you would have to rewrite the whole functionality for each of the implementations or make an abstract class which might be a lot more effort to manage.

[soerensen3]

This functionality is already "implemented" or at least not forbidden. I think in delphi it is, so you could say it is a bug. However you cannot override a constructor for some reason and code completion does not work for any class that inherits this type. I've given an example on this before in another topic.
http://forum.lazarus.freepascal.org/index.php/topic,37278.msg250206.html#msg250206
You will find a compilable example there without interfaces though. If anyone is interested I could supply a complete example with interfaces. However it seems nobody understood what I was talking about, so maybe I'm not good at explaining this.

[sam707]

polymorphism is quite easy to simulate with pascal =>

1) use interfaces when you only need a bunch of common methods (no data) to all "inheriter objects"

2) encapsulate objects inside objects when you need to add more data structures (this will avoid diamond of death) E.G.

suppose you have a class A; a class B; and you need a class C encapsulating A and B

class C = begin class
 a : of type A;
 b : of type B;
public methods
 wrappers methods from A and B
 constructor calling wrappers constructors
end public methods
end class

is moe or less equivalent to crapy C++ class C(A,B)

so I can't believe @Marcov (5-10 years) argument, MINE IS DEF WE WILL NEVER NEVER AND NEVER NEED C++ craps

[Zoran]

Also note that all classes in Pascal are inherited from TObject. Therefore every multiple inheritance in Pascal would create a diamond.

[sam707]

Also note that all classes in Pascal are inherited from TObject. Therefore every multiple inheritance in Pascal would create a diamond.

+1
and break structured programming (and RTTI) forever

[soerensen3]

@Sam: True but is there no overhead because you have to call the methods of either class A or B? Also to my knowledge you would have to write a lot more code because you would have to implement all the functions in class C (at least the headers) again and in the bodies of C you would have to write very stupid boiler plate code (or maybe you can use the implements keyword for interfaces?). If not can you maybe give an example with real code?

[sam707]

@Sam: True but is there no overhead because you have to call the methods of either class A or B? Also to my knowledge you would have to write a lot more code because you would have to implement all the functions in class C (at least the headers) again and in the bodies of C you would have to write very stupid boiler plate code (or maybe you can use the implements keyword for interfaces?). If not can you maybe give an example with real code?

and to your opinion what does a C++ compiler do except try to make assembly code following your "overhead assertion" to make it compat with my preceeding algorithm???

I prefer as long time pascal user to STRUCTURE my code point by point, being sure the compiler won't hang in inheritance guessings!
I worked also many years with Qt (C++), and there where nights I couldn't sleep fighting code because i (or one of my coworker) had wrote lazy code around inheritance, misuderstood by gnu C++.

SO it's a choice, either you prefer C++ craps and being LAZY, either you prefer to structure your mind and your code and being PASCALISH

finally you'll find out being LAZY brings you damn much more work LOL!!!!

[soerensen3]

I don't know (and don't care) what exactly C++ does but if you have a VMT you can simply look for a pointer to the function there and call it directly. With a wrapper class you would have to make a method calling another method. That's what I mean with overhead.
I don't say I'm for multiple inheritance but I understand what the OP (about multiple inheritance not the original OP  ) is saying about an overhead which you cannot get rid of so If you have a pascalish solution for the problem it would opt for your point that it is not necessary but this is difficult without a good code example. In my case I found out that I don't really need the multiple inheritance but in a different case I did not find a "nice" solution yet (A working one though). For me it is fine at the moment because it works, so I would be interested in a solution.
So I'm also not against multiple inheritance per se but if my code I posted before was fully supported it would solve most of the problems already but maybe I don't really understand the exact problem you refer to with "Diamond of Hell" because I never worked with C++.
Do you mean that you can override a method in two classes and it is not clear to the user which method will be called by the compiler? Because this is also possible with single inheritance. Or is it about the order in which inherited methods are called in a method's body?

[soerensen3]

Ok I found this: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem

So I try to show how my solution would solve the problem with the GUI example:

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

1. type
2.   TGUIObject = class
3.      function equals( Obj: TGUIObject ): Boolean; virtual;
4.   end;
5.  
6.   TRectangle < T > = class ( T )
7.      function equals( Obj: TGUIObject ): Boolean; override;
8.   end;
9.  
10.   TClickable < T > = class ( T )
11.      function equals( Obj: TGUIObject ): Boolean; override;
12.   end;
13.  
14.   TButton1 = class( TRectangle < TClickable < TGUIObject >>)  // equals of TRectangle will be called
15.   end;
16.  
17.   TButton2 = class( TClickable < TRectangle <TGUIObject >>)  // equals of TClickable will be called
18.   end;
19.  

So when specializing the generic it is clear which methods to call because it single inheritance actually.
This sentence from the wikipedia page is still true:

Free Pascal uses the "last man standing" rule, where there is a reference to two identifiers that have the same name, whichever is the last one defined is the one that is used. So if there is a Unit A and a Unit B that have a variable named Q, if the declaration is "USES A,B;" then a reference to Q will use B.Q.

[sam707]

huh see what i mean when i wrote "lazy" against structured pascalish? why don't you put "diamond of death c++" into your browser search engine and ... press the [Return] key with one of your hand plenty of fingers? can't choose one??? LOL!!

(I'm gonna be a professional LOLer here)
 

[sam707]

if you need to learn about retreiving methods lists by names or pointers for them to be nicely exported to scriptengine(s) or other programs, and VMTs, i suggest you to install pascalscript package and ... well... if you're a structured courageous pascalish user, ... READ (at least) test and DEBUG (at best)

[soerensen3]

What is it with all the offensiveness? I did not know there was a paradigm of the diamond of death until I did google it. When I googled it I replied that I found the answer already. And I posted code that showed there is no diamond of death in pascal with my solution. Wan't me to start a NewNewPascal? This is how the thread started in the first place. This is only bashing and no discussion. I know now you're against multiple inheritance, I just don't know why because you didn't explain what is wrong with my code (Which isn't even real multi inheritance). The code works already (with function headers and unit stuff added). It is either a bug in the compiler or a broken feature (because of the problems with the destructor and code completion (not in the compiler, I know)) depending on how you see it. It is not the only way to fake multi inheritance by the way. You can also do it with macros and includes but it is kind of ugly.
So can't we just be friendly? It would help the Free Pascal community a lot more than any new feature.
But maybe I got you all wrong and your post wasn't meant as an offense. In this case I didn't get it. Otherwise I'm out of this "discussion" until we are back to normal.

[Mr.Madguy]

What is it with all the offensiveness? I did not know there was a paradigm of the diamond of death until I did google it. When I googled it I replied that I found the answer already. And I posted code that showed there is no diamond of death in pascal with my solution. Wan't me to start a NewNewPascal? This is how the thread started in the first place. This is only bashing and no discussion. I know now you're against multiple inheritance, I just don't know why because you didn't explain what is wrong with my code (Which isn't even real multi inheritance). The code works already (with function headers and unit stuff added). It is either a bug in the compiler or a broken feature (because of the problems with the destructor and code completion (not in the compiler, I know)) depending on how you see it. It is not the only way to fake multi inheritance by the way. You can also do it with macros and includes but it is kind of ugly.
So can't we just be friendly? It would help the Free Pascal community a lot more than any new feature.
But maybe I got you all wrong and your post wasn't meant as an offense. In this case I didn't get it. Otherwise I'm out of this "discussion" until we are back to normal.

Fist of all, interfaces have exactly the same "diamond of death" problem, as multiple inheritance. They have lesser problems, cuz they have lesser features - no fields, no constructors, etc. But remember this? Method name ambiguity, yeah.

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

1. IInterface1 = interface
2.   procedure MyMethod;
3. end;
4.  
5. IInterface2 = interface
6.   procedure MyMethod;
7. end;
8.  
9. TMyClass = class(TInterfacedObject, IInterface1, IInterface2)
10.   procedure MyMethod1;
11.   procedure MyMethod2;
12.   //Diamond of death disambiguation here
13.   procedure IInterface1.MyMethod = MyMethod1;
14.   procedure IInterface2.MyMethod = MyMethod2;
15. end;
16.  

I.e. "diamond of death" - is possible situation only, so it should be dealt with somehow on compiler level. It's programmer himself, who create it. And it's up to programmer to avoid it. I.e. if you don't know, how to properly use some feature - don't just mindlessly use it. Any feature should be used as a tool to solve some problems and one should clearly understand, how it works, not just use it, cuz it exists.

Second. Sorry, that I haven't noticed your code. That's, what I need. Does it really work now? It can be solution of my problems, cuz I was seeing it as some sort of "subclass" feature. Something like this:

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

1. TAbstractClass = class
2.   procedure SomeMethod;virtual;abstract;
3. end;
4.  
5. TSubclass = subclass(TAbstractClass)
6.   procedure SomeMethod;override;
7. end;
8.  
9. //TAbstractClass somewhere in inheritance stucture
10.  
11. TSomeAncestor = class(TAbstractClass);
12.  
13. //Actual implementation
14.  
15. TMyClass = class(TSomeAncentor);
16.  
17. //Now we subclass it
18.  
19. MyObject := TMyClass.Create;
20. Subclass(MyObject, TSubclass);
21. //Or may be
22. TSubclass.Subclass(MyObject);
23. //Or another variant
24. NewObject := TSubclass.Subclass(MyObject);
25.  

And your code does exactly the same, but statically.

[soerensen3]

Partly, I tried it again, but found that you cannot override methods at all because it always complains it could not find the method in the base class. I didn't need to for my purposes. Except for that, it works, but I would't want to rely on it especially in productive code, to be still working in the future.
If you like a more future proof version which does exactly the same but looks ugly you can use this.

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

1. //testclass.inc
2. {$IFDEF INTERFACE}
3. type
4.   TTestClass = class ( T )
5.      procedure SomeProcedure; override;
6.   end;
7. {$ENDIF}
8. {$IFDEF IMPLEMENTATION}
9. procedure TTestClass.SomeProcedure;
10. begin
11.   WriteLn( 'TTestClass.Some procedure' );
12. end;
13. {$ENDIF}
14.  

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

1. ...
2. interface
3.   {$MACRO ON}
4.   {$DEFINE T:= TSomeParent}
5.   {$DEFINE TTestClass:= TMyTestClassWithSomeParent}
6.   {$DEFINE INTERFACE}
7.   {$INCLUDE testclass.inc}
8.   {$UNDEF INTERFACE}
9.   {$UNDEF T}
10.   {$UNDEF TTestClass}
11.  
12. implementation
13.   {$DEFINE T:= TSomeParent}
14.   {$DEFINE TTestClass:= TMyTestClassWithSomeParent}
15.   {$DEFINE IMPLEMENTATION}
16.   {$INCLUDE testclass.inc}
17.   {$UNDEF IMPLEMENTATION}
18.   {$UNDEF T}
19.   {$UNDEF TTestClass}
20.  
21. end.
22.  

I attached a fully compilable example. If you really need this feature than this is your solution. It makes the code less readable though. My other code would be a solution if it was fully implemented.

[Mr.Madguy]

Yeah, unfortunately this doesn't work. Lazarus complains about no method to override and Delphi is even smarter - it gives "Class type required", when declaring TSubclass. Looks like this fact, that you can do it in Lazarus - is simple bug, that allows undocumented behavior.

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

1.   TAbstractClass = class
2.     procedure DoSomething;virtual;abstract;
3.   end;
4.  
5.   TImplementationClass = class(TAbstractClass)
6.     procedure DoSomethingElse;
7.   end;
8.  
9.   TSubclass<T:TAbstractClass> = class(T)
10.     procedure DoSomething;override;
11.   end;
12.