http://lists.freepascal.org/pipermail/fpc-devel/2018-May/038886.htmlI think you overreacted. But maybe this was just the straw that breaks the camel's back.
Will your repository at least be connected in some way to perhaps Graeme G's mirror of the official trunk, so that people who want to attempt to keep it in sync can do local merges themselves?
I respect both of you and both of you know that. Will be OK. Don't be silly....No point to it.... O:-)
The one is over-protective the other one is like a little child that wants to push too hard.
Oh, well... :P
My impression is there is not a personal dislike, just a strongly phrased matter of opinionated minds.
Which is actually a good thing
I and I alone take full responsibility. I have only warned Florian Klaempfl in advance that this could happen, none of the other members have anything to do with this.
Sad news, especially that the Generics.Collection will no longer be maintained within FPC trunk.I'll probably keep a look on Maciej's changes there and reintegrate them with trunk (as long as he doesn't change the license to something incompatible that is :P )
This is all (in the case of any conflict between master and freepascal branches, additional action from my side is needed, but the conflicts are rather rare).
@bee every idea is welcome in NewPascal, I was not thinking about this feature yet, but looks promising and is worth to investigate! This may be a little delayed because I have a lot of work with reactivation of NewPascal. But when I finish I will back to this for sure.
they say variables aren't initialized for example, but everyone knows that of course they are.....What make you think that? (Global) Variables on the heap may be initialized - that's implementation detail, imo -, but local variables are not!
@Bee: Am I the only one who has noticed that the doc links on the FPC website still direct to the 3.0.2 docs, even though the 3.0.4 docs obviously exist? And there's more than a little bit of incorrect information in them in general as well... they say variables aren't initialized for example, but everyone knows that of course they are.....
And I heard that FPC already has a foundation or something. Does it mean it finally has some kind of financial support? If that so, I think they need to hire professional people to do these things:
1. Migrate all the codes to github so it's more visible to the outside world, including the code management tools (issues, etc).
2. Build a great and complete documentations.
3. Make a brand new website and forum that looks modern.
4. Plus make some marketing noises on the internet and social media.
Let the world knows that we have a new and modern Pascal.
This is the kind of stuff that should have been focused on a long time ago IMO, instead of stuff literally nobody cares about at all... (Seriously, what's with all the i8086 compiler target commits in the trunk recently? What a completely pointless waste of time.)
As has been said many times anything that goes on in fpc is made by volunteers in their own time and not steered by a project lead or any milestones.Indeed. However, leadership and management is still required though, it's a project after all. Leadership is required to maintain the vision of the project and management is required to keep the project on the track. That's why some other voluntary-based open source projects have some kind of a board like in a company. I think both FPC and Lazarus lack of true leadership and management, but more on seniorship and skill. If you've been with FPC long enough or you contribute lots of code to FPC, then you got some respects. It needs more than that to keep these huge projects go well with time and new people.
Changing stuff in the front end on the other hand has a tendency to affect everyone so it has to be done really carefully so you can keep trusting fpc to be a high quality compilerA high quality compiler is not only talking about stability and performance, but also about features. Turbo Pascal is really a high quality compiler, technically speaking, but it's useless because it doesn't provide many features of modern programming.
As has been said many times anything that goes on in fpc is made by volunteers in their own time and not steered by a project lead or any milestones.Indeed. However, leadership and management is still required though, it's a project after all. Leadership is required to maintain the vision of the project and management is required to keep the project on the track. That's why some other voluntary-based open source projects have some kind of a board like in a company.
I don't know if Izak would or could keep his promises, but it's good enough for me to switch to NewPascal once it goes public and stable.
Like? Usually such structure only comes when donations or sponsors are high enough to actually have resources to direct.
There are no donations and sponsors because project is not big enough and project is not evolved significantly ...
Like? Usually such structure only comes when donations or sponsors are high enough to actually have resources to direct.
But then we have here a chicken egg problem again. There are no donations and sponsors because project is not big enough and project is not evolved significantly because there are no money to pay developers.
So the usual answer that the feature XYZ can be implemented because it is a volunteer project and there are no resources to do that is simply not good for most of us. You can't get donations and sponsors overnight. But there can be an active effort to get there once. And nobody would say that it is an easy task. But without it, FPC and Lazarus will be still the same small limited projects for many years to come.
Like? Usually such structure only comes when donations or sponsors are high enough to actually have resources to direct.
But then we have here a chicken egg problem again. There are no donations and sponsors because project is not big enough and project is not evolved significantly because there are no money to pay developers.
Maybe, but probably the area of the project is not popular enough to get to that size any which way.QuoteSo the usual answer that the feature XYZ can be implemented because it is a volunteer project and there are no resources to do that is simply not good for most of us. You can't get donations and sponsors overnight. But there can be an active effort to get there once. And nobody would say that it is an easy task. But without it, FPC and Lazarus will be still the same small limited projects for many years to come.
First, that still doesn't solve the governing problem, you can't assign volunteers, and not everybody can do all tasks.
Second, all manpower that you theoretically could reassign will leaves holes elsewhere.
https://www.firebirdsql.org/en/snapshot-builds/
https://www.firebirdsql.org/en/server-packages/
https://www.firebirdsql.org/en/development/
I am talking to some friends so we can get some money to sponsor some new people (younger than 30, maybe college students) to solve some old annoying small bugs or some old missing small features.
...
If there is a little more money, we would think of servers and knowhow for Continuous Integration (CI) for both FPC and Lazarus. This solution would became an actual example for everybody.
Maciej, stop it. Work it out. These kind of comments aren't very helpful.I am opened to continue my work for community, not for Michael but I have ban from Michael which is also boss of FPC foundation. How can I contribute bug fixes for compiler, updates for my libraries without access to trunk and core mailing list?
You know I respect and test your contributions.
use the bugtracker, attach the diff of the files to a bug report and walk away, if you really want to do. If not then as long as your repo is online and accessible by the team then they can pull what ever they need.Maciej, stop it. Work it out. These kind of comments aren't very helpful.I am opened to continue my work for community, not for Michael but I have ban from Michael which is also boss of FPC foundation. How can I contribute bug fixes for compiler, updates for my libraries without access to trunk and core mailing list?
You know I respect and test your contributions.
on ML you mentioned: "I have ban for FPC core mailing list (no more "Daily test suite diffs" for me)".
What are "Daily test suite diffs"?
Now I think I understand why CodeTyphon chose its way. Rather than contributing directly to the project, Sternas (CT's author) simply took the project with him and do it his way so he didn't need to bother with core devs approvals and agreements.I think this conclusion is not accurate.
Although he did some nasty things with the licenses, but look… FPC/Laz devs don't mind, even support him.Are you sure they don't mind? Who supports him?
So, I think Maciej's decision to work on his own FPC fork is correct. As long as he keeps following FPC development and base his work on it, I'll support him.Sincere question: Why do you want him to base his work on the work of "a bunch of old people"?
use the bugtracker, attach the diff of the files to a bug report and walk away, if you really want to do. If not then as long as your repo is online and accessible by the team then they can pull what ever they need.
Sincere question: Why do you want him to base his work on the work of "a bunch of old people"?
I was thinking about using FPC bugtracker as normal user (this is how was looking my work before). What I can say : In many cases filling bug report, preparing *.patch takes more time than fix and commit to trunk. Redundant work (especially for minor fixes). Someone needs to assign bug report, apply the patch and commit (some patches waits few years !sic so filling bug reports for sport is not practical). Because of someone's "strange" decision we need to waste many of the important time. Doing this in current situation is also demotivating. Probably I should continue detailed list of changes like :
https://www.firebirdsql.org/en/snapshot-builds/ftp://ftp.freepascal.org/pub/fpc/snapshot/v31/Quotehttps://www.firebirdsql.org/en/server-packages/Seems to be regular release. We have that.
ftp://ftp.freepascal.org/pub/fpc/dist/3.0.4/Quotehttps://www.firebirdsql.org/en/development/https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi
Any help increasing coverage and frequency welcome, but it is all basically there.
Whenever I need to compile a new version of my cross platform tools, I do it like this :
Copy code to OSX system. Compile and build.
Copy code to Windows virtual machine. Compile and build.
Copy code to Linux 32-bit distribution virtual machine. Compile and build.
Copy code to Linux 64-bit distribution virtual machine. Compile and build.
Upload binaries, executable and OSX app file to web server.
As you might imagine, that is a bit of a faff!! And can be frustrating, especially if you get to the end of even half way through and realise I've forgot to update a form caption or something and so have to repeat it all!
Someone mentioned that if code is on GitHub, the build process can be automated for all three systems using continuous integration.
....
I realize in the project settings you can change the target CPU and so on, but I've never yet successfully managed to create, for example, a Linux binary on a Windows system. So I've always just done it as stated in the steps above.
Any guidance welcome.
For example if I want to get automatic development builds of a program made with lazarus with one of the CI tools available online (appveyor). There's a tutorial on how to do it?
It for example needs some packages installed in the IDE to work.
I'm intrigued since I recently seen an appveyor file in New Pascal.
And if is not possible don't mind. Is a specific question, I know I can automate that in my machine too, but I'm asking about online services.
I've been working on an fpcunit listener that writes fpcunit test results to a database instead of an XML file: handy to be able to compare results between runs and detect regressions.
My aim was to make the code cross-database friendly (using portable SQL) and normalize the database so it can be used for a lot of test results (e.g. in Continuous Integration server kicked off by SVN commits).
I've been using it with a remote Firebird database server in my Jenkins CI server for the dbtestframework tests (see http://wiki.lazarus.freepascal.org/Jenkins#FPCUnit.2FDBTestframework_tests_with_database_output (http://wiki.lazarus.freepascal.org/Jenkins#FPCUnit.2FDBTestframework_tests_with_database_output))
By now, I think I've got the test listener code working well from a functional perspective and I'm now looking at improving performance without sacrificing storage size/normalization.
I was thinking of solutions similar to:
https://jenkins.io/
https://travis-ci.org/
https://www.gocd.org/
To easy and improve environments such as:
On one side, everybody agrees that both FPC and Lazarus need more and more volunteers, especially from younger generation to ensure these great projects will have a bright future. But on the other side, sometimes new people aren't very welcome to contribute if this new people doesn't conform to the seniors way of thinking. This Maciej's case is the latest example, but I've seen similar cases since I joined FPC/Lazarus.+1
On one side, everybody knows that we need to get popular so this project could attract both volunteers and fundings, especially from younger generation. But on the other side, I don't see much effort has been done to overcome this problem. The core devs barely think about it, because they mostly think about the technical things. I don't blame them because it's their focus and concern, but if nobody would tackle and handle these non-technical problems, then we'll getting nowhere. We'll be forever a niché in software development. Nobody cares about Pascal but a bunch of old people who still maintaining their projects in their niché market.+1
Now I think I understand why CodeTyphon chose its way. Rather than contributing directly to the project, Sternas (CT's author) simply took the project with him and do it his way so he didn't need to bother with core devs approvals and agreements. Although he did some nasty things with the licenses, but look… FPC/Laz devs don't mind, even support him. So, I think Maciej's decision to work on his own FPC fork is correct. As long as he keeps following FPC development and base his work on it, I'll support him.So far, I have never used CT, but reading discussions on this forum, it seems that CT's author motivations were more economical than philosophical.
Maybe it's time for FPC and Lazarus to have a new "competitor" other than DelphiI know that my opinion is not relevant here since I am neither a core developer nor a patcher, but I still think that work together is better than forking in the open source world.
Maybe it's time for FPC and Lazarus to have a new "competitor" other than Delphi so they will start to be more open minded accepting new ideas from new people.Considering recent examples such as PHP x Hack (HHVM), PHP evolved very fast after Facebook competition had created Hack based on PHP.
If Maciej keeps continuing his work and regularly release stable New Pascal with new features that offers something more than the orginal FPC, I'm sure New Pascal would have its own users and fans. Just like CodeTyphon.Unfortunately, you are probably right.
For major work and restructures, yes this can take some while. For short patches it is significantly quicker.For short patches generally it works in this way, but this is not the rule. If no one from core is interested, the patch can wait long time (even short patch). If I have ban for trunk without rational reason, I think that my patch can be rejected also without rational reason also my bug report can be simple ignored with malice (what I'm afraid of). The general fact about redundant work from my side is still valid. Could you explain me the sense of redundant work? Why I am forced to fill bug report for every minor thing instead of working on more fixes?
I understand and respect you point of view.I was thinking of solutions similar to:
https://jenkins.io/
https://travis-ci.org/
https://www.gocd.org/
To easy and improve environments such as:
Ok, so for development of applications WITH Lazarus and FPC, not development ON lazarus and fpc.
Lazarus ran Jenkins for a while, iirc if after a commit there was no new commit in 5 minutes or so.
Personally, I think it is more stuff for teams than for single developers. Getting deep into these systems also takes time, and for one machine administered by one person a few simple scripts are easier. At least IMHO.
Of course it probably it is less of a problem if you already use some of the techniques, but I don't maintain any LAMP or alternatives (webservers, web serverside scripting languages, and I haven't touched Java seriously in a decade), both experience or maintenance, so for me that would be all extra burdens just to use one of these packages and or develop plugins for them.
Afaik Lacak who does a lot of SQLDB work, has an own testsuite.
I was thinking of solutions similar to:
https://jenkins.io/
https://travis-ci.org/
https://www.gocd.org/
The Michael said that CI is almost impossible to fully integration with FPC. IIRC he said that CI can't be used for generation of documentation and he need to do some things manually. If I am wrong please someone to correct me. In my opinion such thing should be also possible with CI, but maybe there is some problem which I am not aware of (I didn't trying to use CI for FPC documentation).
Why not? Technically speaking CI servers just run scripts!
wait, gurus....It is a fork. With a focus on Delphi syntax (which is good imho)
This discussion has given me a bigbang headache because I couldn't catch what really we are talking about.
Before going more further, so please,
1. what is "NewPascal" meaning? (I visit the link and found nothing about technical advantage upon fpc)
Is it a brand new pascal dialect compiler (like PicPas doing) ?
2. What is the "modern" things which NewPascal provides?Not many, yet. If any at the moment.
3. In which situation NewPascal will beat better than fpc/trunk can do?Possibly - but I did not see any real evidence yet - quicker -riskier? -implementation of some more Delphi compatible features, like ARC, anonymous methods (compiler) and extended generics (very good implementation, but also in fpc trunk). None of these are in NewPascal yet, as I understand. (Correct me if I am wrong Maciej)
What I understood is: Mormot will deadly depend on NewPascal, but I don't know the detail reason.
:-*
---correct me if I wrong
1. what is "NewPascal" meaning? (I visit the link and found nothing about technical advantage upon fpc)
Is it a brand new pascal dialect compiler (like PicPas doing) ?
2. What is the "modern" things which NewPascal provides?
3. In which situation NewPascal will beat better than fpc/trunk can do?
What I understood is: Mormot will deadly depend on NewPascal, but I don't know the detail reason.
On one side, everybody agrees that both FPC and Lazarus need more and more volunteers, especially from younger generation to ensure these great projects will have a bright future. But on the other side, sometimes new people aren't very welcome to contribute if this new people doesn't conform to the seniors way of thinking.
This Maciej's case is the latest example, but I've seen similar cases since I joined FPC/Lazarus.
On one side, everybody knows that we need to get popular so this project could attract both volunteers and fundings, especially from younger generation.
But on the other side, I don't see much effort has been done to overcome this problem.
The core devs barely think about it, because they mostly think about the technical things.
I don't blame them because it's their focus and concern, but if nobody would tackle and handle these non-technical problems, then we'll getting nowhere.
We'll be forever a niché in software development. Nobody cares about Pascal but a bunch of old people who still maintaining their projects in their niché market.
Now I think I understand why CodeTyphon chose its way. Rather than contributing directly to the project, Sternas (CT's author) simply took the project with him and do it his way so he didn't need to bother with core devs approvals and agreements.
Although he did some nasty things with the licenses, but look… FPC/Laz devs don't mind, even support him.
So, I think Maciej's decision to work on his own FPC fork is correct. As long as he keeps following FPC development and base his work on it, I'll support him.
Maybe it's time for FPC and Lazarus to have a new "competitor" other than Delphi so they will start to be more open minded accepting new ideas from new people.
If Maciej keeps continuing his work and regularly release stable New Pascal with new features that offers something more than the orginal FPC, I'm sure New Pascal would have its own users and fans. Just like CodeTyphon.
Marco,
Well written.
Tnx.
NewPascal means New(Pascal) ^^. NewPascal sooner or later will be also new mode/dialect for compiler.I don't need much. I just need my crazy Delphi code to compile.
For major work and restructures, yes this can take some while. For short patches it is significantly quicker.For short patches generally it works in this way, but this is not the rule. If no one from core is interested, the patch can wait long time (even short patch).
If I have ban for trunk without rational reason, I think that my patch can be rejected also without rational reason also my bug report can be simple ignored with malice (what I'm afraid of).
The general fact about redundant work from my side is still valid. Could you explain me the sense of redundant work? Why I am forced to fill bug report for every minor thing instead of working on more fixes?
The Michael said that CI is almost impossible to fully integration with FPC. IIRC he said that CI can't be used for generation of documentation and he need to do some things manually. If I am wrong please someone to correct me.
In my opinion such thing should be also possible with CI, but maybe there is some problem which I am not aware of (I didn't trying to use CI for FPC documentation).
I don't need much. I just need my crazy Delphi code to compile.
What I want to add, is that it's actually dream of every programmer - to add features directly to compiler in order to make code more simply. I would personally add some meta-programming features to compiler in order to remove some routine code from my projects, that could be automated by compiler, so there would be much less room for errors. Some sort of advanced operator overloading. And also some multiple inheritance improvements, such as "subclass" feature or something.
Spite is not sensible either. If you have minor patches to stuff already in trunk, please commit them.
Let's all cool down, and get some work done.
I fully understand this and this is for sure subject of my work. The idea of non existing yet "NewPascal" dialect is strong support for meta programming in very clean "Pascal" way with full assistance of existing dialects and well known RTL. The tools like YACC or boost:spirit library should be replaceable by NewPascal dialect in long term future.I just hate, when code becomes overcomplicated due to compiler limitations. For example multiple inheritance problem. Standard situation:
I just hate, when code becomes overcomplicated due to compiler limitations. For example multiple inheritance problem. Standard situation:
And I also need some meta-programming features to automate some code. I even have idea of MetaPascal™©® compiler, where compiler itself would be built fully via meta-programming tech, i.e. adding new features wouldn't require compiler modification - it would work like adding new units to your project. That's my dream.
This is my dream too :). Anyway the fast revolution is not possible. Rather evolution with start with new NewPascal dialect (which will initially get what is the best from delphi mode and objfpc + some new more oxygene like features).
This is controversy topic. But some kind of multiple inheritance should be possible with some extensions for "default field". But this is field of research, and for sure eventually "multiple inheritance" will be solved in other way than in C++. This is very dangerous play and is very easy to hurt language.Limited version of multiple inheritance is possible now - via interfaces. And interfaces are actually implemented the same way, as multiple inheritance in C++ - via wrappers, that add some delta to Self reference. So, performance wouldn't be hurt, if we would switch from interfaces to multiple inheritance. And... Using interfaces feels like a crutch programming. They have several drawbacks - no fields, mandatory reference counting, explicit casting via using GUID, etc. And, dunno about FPC, haven't tested it yet, but in Delphi I can't even implement base interface and it's descendants in the same class - I have to use aggregated interfaces and this is as bad, as just using "driver" model.
I experienced the joy of metaprog in D and rich of this experience i can say that it's clear that's it's not possible in FPC. This requires multi-pass semantic, templates, and the most important, compile-time reflection. Object Pascal RTTI is an old but well working feature (used for the LCL GUI serialization for example ;) ) but it's not at all adapted to metaprog.Meta programming doesn't have to be dynamic. I see meta programs as compiler plugins. Something like Lazarus packages. You write "uses MyMetaModule;" this meta-module have some special structure. First compiler compiles it into some sort of MyMetaModule.dll plugin file (static linking to compiler itself - isn't good idea in this case) and then loads it and compiles program itself using it's features. Something like that.
Too much changes to the compiler and language. Maybe a kind of pre-processor could work, to some extent.
I don't think a fork is a good think - it depletes the resources on both.
But I also don't think that an opensource project should ban contributors, because that has the same effect.
...
An opensource project works on donations. But why donate when the things you want aren't done? Why donate if you have no saying at all in the priorities?
Therefore some suggestions:
1. Don't ban code contributors
2. Make a request list where anyone can add their wishes (needed fixes, needed syntax sugar, needed functionality)
3. Give donators votes to vote on this request list (the more you donate, the more votes you get)
4. Pay a fee (from the donations) to the developers to do the work on the most requested items
So, while we're talking about a new and modern Pascal, can you provide named parameter feature? I think it's good and fit with Pascal's philosophy.Does it? It fits in Python philosophy...
@bee every idea is welcome in NewPascal, I was not thinking about this feature yet, but looks promising and is worth to investigate! This may be a little delayed because I have a lot of work with reactivation of NewPascal. But when I finish I will back to this for sure.
If such a feature should exist, wouldn't it be more straightforward to simply not specify anything before the comma? (i.e. "Fly(, Amelia);")
It is actual Visual Basic philosophy. Not a good idea for register allocation and parsing. Can be done. I'd rather not see it in Pascal.So, while we're talking about a new and modern Pascal, can you provide named parameter feature? I think it's good and fit with Pascal's philosophy.Does it? It fits in Python philosophy...
Personally, I'm not a big fan of this feature at all, but I should say that the way proposed by this comment appeals much more to me than writing parameter names in function calls.Where's the "feature" in that proposed "feature"?
So, when (if ever) you start working on this, please think about the latter way.
Does it? It fits in Python philosophy...Many programming languages share some same principles, concepts, and philosophy. There's no such a programming language that truly unique in its whole concepts and principles. Some reasons why I love Pascal are the clarity, readability, and discipline. Though sometimes I feel it too verbose, but in the end I realize that it's Pascal, that's the way it is. If I need a different concepts and principles, I should use other programming language that fits my need better.
If such a feature should exist, wouldn't it be more straightforward to simply not specify anything before the comma? (i.e. "Fly(, Amelia);")No, it's very not pascalish. Comma is a punctuation. It completes something else. So, it should not exist all alone by itself. If you don't want to specify something then don't specify at all.
Personally, I'm not a big fan of this feature at all, but I should say that the way proposed by this comment appeals much more to me than writing parameter names in function calls.Then it's not for you. But I think it's good that it's available as an option. I'll use it for sure.
I found that someone asked for it here: http://wiki.freepascal.org/Feature_Ideas#.22default.22-value_in_a_proc_or_function_call (http://wiki.freepascal.org/Feature_Ideas#.22default.22-value_in_a_proc_or_function_call)Yeah, I would also want this feature. And I don't really understand, why there is such limitation - only last procedure/function parameters can have default values? It's purely meta-programming feature. I.e. if any parameter is skipped - it should be replaced with default value. As simple, as that. I.e. something like this should work:
And I also don't see, why such declaration is impossibleIt's purely matter of Pascal standard - there is no such thing, as parameter skipping or default parameter symbol (something like "_" symbol) there. And this is purely parsing problem, I guess.
Previously I had been giving you examples only, but I've analysed situation and, yeah, I have a list of features, I personally want to see in Pascal. Funny thing - I've never programmed on C/C++ seriously, but all my problems with Pascal boil down to lack of certain C/C++ features:
1) Delphi 2009 support, i.e. generics, closures and full Unicode support.
2) Multiple inheritance. Yeah, I can emulate it in Pascal, but my code suffers from memory usage and performance penalties, cuz code isn't optimized at binary level. Yeah, for example I use exactly the same wrappers, but they obviously aren't just ADD EAX, X and JMP Y. And of course it causes unclear and low quality code.
3) Extended operator overloading support. Overriding default := handling, similar to C/C++ "operator =" for example. Shorter explanation - I need to automate some assignment and initialization/finalization code for classes in a similar way, interfaces are handled, but without actually using interfaces.
1) Support for Delphi "new" features is always welcomed. I would personally like to have kind of FreeDelphi rather then FreePascal.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. Otherwise I wouldn't be able to reuse code and that would mean copy-pasting exactly the same code many times, wasting memory on lots of references and extreme code size inflation. This is extremely clunky solution and means large memory usage and performance penalties. And while multiple inheritance implementation isn't free and uses similar methods, it's optimized at binary level, as in this case compiler knows, what should be done - for example wrappers have minimal possible code. And code becomes much more clear, readable and consistent. I've just tested my ideas in Borland C++ 3.1 - even this archaic compiler do this job perfectly.
2) Multiple inheritance is problematic and usually not worth the cost. Therefore many language designers decided to not allow it.
3) This style operators overloading is already supported by FPC. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Operator_Overloading_%28Delphi%29
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.I don't think, that container pattern is rare.
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
Make sure first VMT entry you are interested in start at offset 0. The FPC default entries have negative offsets, just like Delphi.
3) Assignment operator isn't supported, as I know. You can't declare "operator Implicit(A:TMyType):TMyType" - compiler would complain about it.
friends are not container patterns - the opposite is true - and are easily implemented with interfaces.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:
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.
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:
with NewPascal you can use management operators: AddRef and Copy instead of "operator Implicit(A:TMyType):TMyType", see:Yeah, that looks like what I actually want. But how about automated try...finally...end feature, interfaces have?
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?Finalize operator is called even when exception occurs, so you don't need to use "try finally end" for records with Management Operators.
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.
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.
Multiple inheritance would make me freeze the last build before it was introduced and never look forward again.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.
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.
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...)
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...)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".
Show us the code..... I don't believe there is no clean solution...(and the above is highly inadequate)
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.
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.
my 2 cents on multiple inheritance =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.
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
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... :D :P ;)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.
... and in 25 years we had time to do it if useful you can thrust that :-*
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+1
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
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.
Also note that all classes in Pascal are inherited from TObject. Therefore every multiple inheritance in Pascal would create a diamond. %)+1
@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???
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.
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.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.
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.
Looks like this fact, that you can do it in Lazarus - is simple bug, that allows undocumented behavior.This is also my guess.
That code is bollocks in any language. Bad code is bad code. Bad programmers are bad programmers. And even proper programmers can write bad code (you just did:QED).
That code is bollocks in any language. Bad code is bad code. Bad programmers are bad programmers.
A thoroughly good example, btw, of such nonsense. It is a recursion and can not be resolved to be precise (not even in C++).
Start withWhich is also nonsense (Of course a class is a class...), but better nonsense....
That code is bollocks in any language. Bad code is bad code. Bad programmers are bad programmers. And even proper programmers can write bad code (you just did:QED).Well, that's not my code. soerensen3 has said (http://forum.lazarus.freepascal.org/index.php/topic,41128.msg285945.html#msg285945), that such pattern works and it interested me. I've tired it and found out, that even if it partially works - it's compiler bug, as Delphi doesn't allow this trick.
A thoroughly good example, btw, of such nonsense. It is a recursion and can not be resolved to be precise (not even in C++ syntax).
Start withWhich is also nonsense (Of course a class is a class...), but better nonsense.... O:-) 8-)
I guess, if this trick would work, this:would resolve into this:
TAbstractClass<Classes.TPersistent> inheritance:
TAbstractClass<Classes.TPersistent>
TPersistent
TObject
-----------------
TAbstractClass<Classes.TStringList> inheritance:
TAbstractClass<Classes.TStringList>
TStringList
TStrings
TPersistent
TObject
-----------------