Rudy Velthuis

If it were so desirable and/or so easy to maintain the Delphi compiler, I wonder why FPC didn't make Delphi obsolete already. I guess because after all there are not so many people capable of maintaining, nor enough people inclined to do it. I also gues that the task is not so easy. I have said it before, and I'll say it again: I use a lot of open source and I love open source and I have participated in open source, but the notion of "open source it so you can always fix it yourself" is pure nonsense. Even if I suffer from some bugs (and indeed, Rio seems to have quite some new bugs and slowdowns caused by the -- incompletely -- removed mrecords, i.e. the runtime changes still affect current code, even if mrecords themselves were removed again), I am not capable nor willing to read the entire (possibly hard-to-read) source code of the entire compiler and then I'm not capable of making a decision what I can safely change without causing a multitude of other bugs. I will leave that to others. I am not so sure there are enough "others" who could or are willing to maintain the Delphi compiler. Nor am I willing to hire someone to fix them for me. People who could do that would probably require large fees too. So no, open sourcing the compiler is useless, IMO. Rather lean on Embarcadero and confront them with "love withdrawal" or other sticks behind your back and let them do it. I agree we need bug fixes and new features. But open sourcing won't provide them. Only pressue on Embarcadero can.

They are not **objects** that can actively reference **other** objects. See how this doesn't even work for interfaces. What makes you think it would be different for objects? Again: no, they can not easily live together What bar? Are you talking about a passive string again?

I didn't know that, but it looks like it has the equivalent but opposite meaning of reintroduce in Delphi. Of course it is useful, in C++ too.

So do loops in other languages. And even a simple language like C has while, do while and for loops. I don't see that as overkill. You use what best suits you. After all, carpenters often have different kinds of hammers (and different kinds of planers) too. <g>

Heh, that doesn't even work properly for interfaces, even if they are not refcounted, You can make objects not being refcounted, but they would still live in an ARC environment, with al the possible problems and disadvantages. Note that your example contained a string constant, not just a non-refcounted object. Obviously you thought about it, but didn't think this through to the bitter end. So again: no they will not coexist easily.

You are really an expert in convincing others to support your ideas. Using a tone like that is certain to win them over. <g> I did not read the entire topic (7 pages an counting...) and I will not. If you had anything useful to say, then repeat it. But no matter what you wrote, I'll write it again: no, they won't easily coexist at all.

they would coexist just fine. No, they would not. Note one bit. The only objects that could co-exist would be manually and automatically refcounted objects. But normal objects are not refcounted, in Delphi (unlike in macOS and iOS). So again: no, they would not easily coexist at all!

I see you are an expert in making friends. <g>

That is actualy the documented way to do this. I wondered why it took so long before someone came up with it. OP probably comes from C++, where directives like override, reintroduce or overload are not necessary. If the signature is different, it overloads and does not hide.

Hmmm... Seeing a lot of code that shows that many people have big problems with it, I get the impression it is an expert skill. Even many people who think they mastered it do it wrong, IME. Indiscriminate use of FreeAndNil() is one sign (code smell) of such imagined mastery.

The disadvantage of C/C++ for-loops is that the end condition is always evaluated, unlike Pascal's, where it is only evaluated on entry. OTOH, this can be an advantage too. The syntax (init; end condition; looping) is nice, but they should not have called it "for".

begin ... (PRecLine(vList.PList)+0{Index}).VirtualNode := vNode; ... end; Or: {$POINTERMATH ON} ... begin ... PRecLine(vList.PList)[0].VirtualNode := vNode; ... end;

The big advantage is that they don't need special handling (implementing methods) or care (like "don't mix interface and object references to the same instance"), that they really represent an IS-A relationship and that they can contain implementation, i.e. there is no need to first define an interface and then to implement it. Classes that really only do one thing (unfortunately, this is not always the case) can often use such inheritance. Every descendant of TStrings IS-A TStrings. See how they are used throughout the VCL and RTL and how useful they have been over many many years. The fact that you are forced to inherit from a certain base class has its advantages. Also think of, heheh, TInterfacedObject, from which almost every interface-implementing class must inherit. Both interfaces, which allow you to program to the interface cross-hierarchy and abstract classes, which allow you to program polymorphically without the hassle of having to implement an interface and refcounting, have their davantages and disadvantages. Do not discard one of them. Use the kind that is best for the purpose. Polymorphism is not limited to inheritance:ritance inheritance polymorphism ("subtyping") interface polymorphism ("subtyping") polymorphism through generics and constraints ("parametric polymorphism") polymorphism through overloading and operator overloading ("ad hoc" polymorphism) ... I'm sure I forgot a kind here. And then there is code re-use, which can be done by composition (delegation, aggregation) or class inheritance. Each of these techniques and practices should be used (if possible, i.e. if the language allows it) where they make sense. Do not make the mistake of favouring one over the other.

So are For, While and Repeat. They are structured GOTOs as well, but with a built-in If. The jump is just hidden a little better.

Probably because GPF is called Access Violation (AV) on Windows.

General Protection Fault. He should have four stars, by now.

<sigh> I keep reading that, especially from Delphites, but ISTM that many totally misunderstood "program to the interface". Interfaces (no matter if they are actual language constructs or abstract classes) are fine and have their use, but like with everything, one can overdo it. Not everything is or should be an interface. The author of the article you link to seems to be one of those dependency injection, "interface only" gurus. ISTM that all these techniques should be part of a larger toolbox, not just a toolbox with lots of nails and a few hammers. I am not even sure if the VCL would have been better with interfaces, if they had been available. And the claim "composition is better than inheritance" is just as wrong. Both have their place, and which one should be preferred depends on the situation.

Then write simple wrappers that do derive from a common base class. Especially if SQL parameter handling is different for both, wrappers are the best choice.

In my experience, most internal errors I have seen occur when mixing generics with anonymous methods, or when relying on the new type inference. Look for code that does this. Often, declaring types beforehand instead of on the spot clears them.

I even think that that rule is too strict. It really depends on the situation, and one should not take preference over the other by some rule like that.

Not at all. But there are many websites that will explain the differences, so there is no need to repeat that here, except what Dalija already wrote.

Ok, then I misunderstood. I thought you had written those classes. Then go for the wrapper. Best solution, IMO.

Then I got the wrong impression. I assumed he had written those two classes. In the case he can't use an intermediate, I would indeed use a wrapper class or interface.

I know I am late, but I would simply have an intermediate class deriving from TDataSet, but with the extra properties and methods that both classes should have. The two classes then derive from that intermediat class. And you can specify the intermediate class as the parameter type for functions, etc. Or is that too naive?

Ok, but exactly that (get a PIDL from a file system path) seems to be what OP wants.