NewPascal plans, Generics.Collections and FPC trunk

[Mr.Madguy]

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.

Dunno. I've never had any problems with "with". At the end it's just namespace feature. You just need to understand, how namespaces work - that's it. If you personally don't understand, how they work =/= they're bad feature. Ambiguities don't just magically appear - you create them. Just don't do it and everything will be fine.

Problem is - I don't need multiple inheritance to do something new. I have existing code, I've been developing for several years. I couldn't just give up - I needed to make it work the way, it was required. And I tried EVERYTHING, I could try, to avoid any complexity in my code, while keeping it functional - to make it as simple, as clear and as consistent, as possible. And I use class composition in my code anyway, cuz I have no other choice. Nothing can be worse, than class composition. Nothing can be clunkier, slower and less memory inefficient. So, multiple inheritance would actually make my code better.

I.e. code itself requires this feature. Dunno, how to explain it better. That's, how OOP itself was invented. People were using records and passing them as pointers back them. They just wanted to automate their workflow, make code more clear and consistent. Same here.

And... Interfaces actually work exactly the same way, as multiple inheritance - new VMT is created for every interface implemented, filled with wrapper functions, that add deltas to Self pointer. And implementations are "hidden" inside class, that implements this interfaces. Multiple inheritance actually works exactly the same way - you just can keep implementations separated from each other and mix them in any combinations.

Example: this two are equal.

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

1. IInterface1 = interface;
2. IInterface2 = interface;
3. IInterface3 = interface;
4.  
5. TClass1 = class(TInterfacedObject, IInterface1);
6. TClass2 = class(TClass1, IInterface2);
7. TClass3 = class(TClass2, IInterface3);
8.  
9. TFinalClass = TClass3;
10.  

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

1. class TAbstractClass1;
2. class TAbstractClass2;
3. class TAbstractClass3;
4.  
5. class TClass1:TAbstractClass1;
6. class TClass2:TAbstractClass2;
7. class TClass3:TAbstractClass3;
8.  
9. class TFinalClass:TClass1, TClass2, TClass3;
10.  

[Thaddy]

I've been developing for several years. I couldn't just give up - I needed to make it work the way, it was required. And I tried EVERYTHING,

Like several as in over 40+ years and 35 with a degree?? Now show me the problem you can't fix.... You are being either stubborn or silly. (Note most of my work is done in C++, just in case..., don't hold that against me, I'd rather use Pascal full time. Which I did at some point...)

Show us the code..... I don't believe there is no clean solution...(and the above is highly inadequate)

[Mr.Madguy]

Like several as in over 40+ years and 35 with a degree?? Now show me the problem you can't fix.... You are being either stubborn or silly. (Note most of my work is done in C++, just in case..., don't hold that against me, I'd rather use Pascal full time. Which I did at some point...)

Show us the code..... I don't believe there is no clean solution...(and the above is highly inadequate)

I've already shown structure of my code. This part still can be implemented via interfaces - no doubts. And it WAS implemented this way in version 1.0. Problem is - code was still too complex and it's scalability was bad. If I would want to add new features - I would need to completely rewrite large amounts of code every time. For example I wanted to add "cyclic buffer" feature. As all data access was implemented at implementation level - I needed to completely rewrite all implementations. So I needed another level of abstraction to keep such changes as local, as possible - so called "data access driver". And this one can't be implemented via interfaces, cuz it requires it's own inheritance stucture - via class composition only. And with multiple inheritance it would be possible to implement it via "delegation to sister class".

What is most powerful feature of multiple inheritance? Implementation of abstract class can be bound to class structure at any moment. Class becomes something like Lego - you can connect any parts at any moment. You aren't limited by vertical structure only.

[Thaddy]

What is most powerful feature of multiple inheritance? Implementation of abstract class can be bound to class structure at any moment. Class becomes something like Lego - you can connect any parts at any moment. You aren't limited by vertical structure only.

Hm. You just admitted you really do not understand. The concept you are looking for in an abstract way are interfaces. These work really like Lego blocks.

[Mr.Madguy]

Hm. You just admitted you really do not understand. The concept you are looking for in an abstract way are interfaces. These work really like Lego blocks.

Interfaces - are just different ways to interact with the same implementation. And this implementation obeys ordinal inheritance rules. Only way to modify behaviour of existing implementation - to add descendant class on the top of it, that would override some virtual methods. But what if this "slot" is reserved for something else? Imagine, that my containers have different ways to access data, depending on data itself. This can be achieved via having some abstract "data access" class on a bottom of class structure and implementing it on a top. They may have their own inheritance structure. But what if I need to have another container class, that needs to reuse code of some existing container? It should be implemented as descendant class too, but... We can no longer attach our "data access" classes to the top of it - we need to completely reimplement them, i.e. simply copy-paste the same code. Now imagine, that I need 3, 4, 5, 10, 20 of such containers. And I have 3, 4, 5, 10, 20 data access methods. Will I also need to copy-paste my "data access" classes 3, 5, 100500 times? This is called "scalability problem", you know. No, I don't want to do it. I will use virtual inheritance, multiple inheritance provides. "Data access" classes can be implemented only once. And then I can "virtually" inherit from them at any moment.

I can do this:

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

1. class TAbstractList:virtual TAbstractDataAccessDriver;
2. class TList:TAbstractList, virtual TMyDataAccessDriver;
3.  

This:

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

1. class TAbstractPairList:TAbstractList;
2. class TPairList:TAbstractPairList, virtual TMyDataAccessDriver;
3.  

And this:

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

1. class TAbstractDictionary:TAbstractPairList;
2. class TDictionary:TAbstractDictionary, virtual TMyDataAccessDriver;
3.  

And I can't do the same thing via interfaces. Two or any arbitrary number of parallel inheritance chains aren't possible with interfaces, sorry. And using class composition means storing extra pointers, constantly resolving them to access data and having tons of wrapper functions. It's reasonable in one case only - when I need to share same "driver" class between several instances of "implementation" classes. But it's not my case.

P.S. Multiple inheritance works just perfectly in C++, but I have another problem - problem with templates. All of a sudden TAbstractList<TPair<TKey, TValue>>, I use in Delphi very often, refuses to compile in C++. Both in old obsoleted BC++ 3.1 and in modern C++ Builder. What can be wrong with it? According to docs C++ has even more freedom in using generics, than Delphi.

[sam707]

my 2 cents on multiple inheritance =

I was there when turbo pascal 5.1 discussed if it needed to be implemented. the reslult of the comittee (after 3 days of biggest brains around world conversation) is as simple as follow =>

Please noobinosss PLEASE NEVER add such crap as multiple inheritance into TRUE Pascal because of the so called "diamond of DEATH" that turns C++ into an HELL on medium and large object projects

PLEASE Keep Pascal 's Tradition away from such HELL, or the basic Pascal Concepts fron His Inventor Niklaus Wirtth (meaning "easy to learn, clear, simple, fast compiled with no preprocssing shit)  would be hardly footed and broken away

THANKS

[Mr.Madguy]

my 2 cents on multiple inheritance =

I was there when turbo pascal 5.1 discussed if it needed to be implemented. the reslult of the comittee (after 3 days of biggest brains around world conversation) is as simple as follow =>

Please noobinosss PLEASE NEVER add such crap as multiple inheritance into TRUE Pascal because of the so called "diamond of DEATH" that turns C++ into an HELL on medium and large object projects

PLEASE Keep Pascal 's Tradition away from such HELL, or the basic Pascal Concepts fron His Inventor Niklaus Wirtth (meaning "easy to learn, clear, simple, fast compiled with no preprocssing shit)  would be hardly footed and broken away

THANKS

This same "diamond of death" allows "delegate to sister class" pattern. And, as I've already said: if you don't want to deal with ambiguities - just don't create them. As simple, as that. Interfaces have the same problem - same method names in different interfaces. Dunno about Lazarus, but Delphi has some major problems with them. No overloading possible, even explicit declarations fail with "Missing implementation" errors. I've already provided example with interface aliases, that fails in Delphi.

[hnb]

multiple inheritance is pandora's box, but in any idea something valuable can be found and can be transformed into something new, maybe in other form.

[sam707]

yup @hnb now evrybody here have the true reason why it has never been implemented into pascal for 25 years ...ago... 

... and in 25 years we had time to do it if useful you can thrust that 

[sam707]

... time and bigger brains that you can imagine to implement it 

[Mr.Madguy]

multiple inheritance is pandora's box, but in any idea something valuable can be found and can be transformed into something new, maybe in other form.

May be I don't need multiple inheritance itself - virtual inheritance is more interesting for me. I was thinking about it, as about something like "subclassing" - i.e. when I can create some "subclass", that can override any virtual methods, while not respecting any inheritance structure.

yup @hnb now evrybody here have the true reason why it has never been implemented into pascal for 25 years ...ago... 

... and in 25 years we had time to do it if useful you can thrust that 

Back then it had very clunky implementation, that was very costly...for that time. Deltas right in VMTs, no matter, if multiple inheritance is used or not. But today it doesn't matter anymore - any interface uses wrapper for every method anyway.

[ASerge]

Multiple inheritance - C++ style - is BAD!. Just like "with" is. Multiple inheritance interface style is sane, but we have that already.

+1

Please noobinosss PLEASE NEVER add such crap as multiple inheritance into TRUE Pascal because of the so called "diamond of DEATH" that turns C++ into an HELL on medium and large object projects
PLEASE Keep Pascal 's Tradition away from such HELL, or the basic Pascal Concepts fron His Inventor Niklaus Wirtth (meaning "easy to learn, clear, simple, fast compiled with no preprocssing shit)  would be hardly footed and broken away

+1

[marcov]

I also think MI is too much trouble for too little practical gain. (and I doubt even that little bit of gain)

Moreover, such a major feature will cause a whole new dimension of corner cases with existing features like Generics (which are still stabilizing), unicode (ditto) and various forms of operator overloading.

Whatever you think of MI and similar fundamental changes, now is not the time. Maybe in 5-10 years.

[soerensen3]

Sorry for bumping but did anyone read my post? Because it could be a way to "fake" multiple inheritance with all the benefits but without the "HELL" part and without changing the compiler (At least I think so) much and also without introducing any new syntax but using generics. By using the normal class syntax it is already clear how to deal with name ambiguities.

[marcov]

Sorry for bumping but did anyone read my post? Because it could be a way to "fake" multiple inheritance with all the benefits but without the "HELL" part and without changing the compiler (At least I think so) much and also without introducing any new syntax but using generics. By using the normal class syntax it is already clear how to deal with name ambiguities.

I never did understand how polymorphism works in such case. So how do I work with such class while only knowing it is something spatial?

With interfaces, you get some ISpatial reference from whatever and work with that.