Stefan Glienke

It's mentioned in the "A bit of history" paragraph of the article you linked to yesterday - it's as if you write code like this if Sender is TComponent then //... do something else if Sender is TButton then //... do something else You clearly will never reach the code for TButton Clearly the interface inheritance clashes with the fact that you can implement a derived interface but not the base one. Probably this is why COM in .NET behaves a bit differently: https://social.msdn.microsoft.com/Forums/vstudio/en-US/7313191a-10db-4a16-9cdd-de9fb80b378a/com-interop-base-class-properties-not-exposed-to-com?forum=csharpgeneral

You know that bugs can be in implementation and also in design See this code: type IFoo = interface ['{1E77F313-1C93-4A59-957B-751FB23EC63F}'] procedure Foo; end; IBar = interface(IFoo) ['{49FC3BDA-7A09-4596-A80C-5EBEF73BA201}'] procedure Bar; end; TFooBar = class(TInterfacedObject, IFoo, IBar) public procedure FooFoo; procedure IFoo.Foo = FooFoo; procedure BarFoo; procedure IBar.Foo = BarFoo; procedure Bar; end; { TFooBar } procedure TFooBar.Bar; begin Writeln('Bar'); end; procedure TFooBar.BarFoo; begin Writeln('BarFoo'); end; procedure TFooBar.FooFoo; begin Writeln('FooFoo'); end; var bar: IBar; foo1, foo2: IFoo; begin bar := TFooBar.Create; bar.Foo; bar.Bar; foo1 := bar; foo1.Foo; foo2 := bar as IFoo; foo2.Foo; Readln; end. The Foo method is implemented differently for IFoo and IBar but depending on how I get an IFoo I get one or the other. Now we can run circles around this and argue back and forth - fact is that they clearly missed the opportunity to specify if you want to also let the compiler implicitly put the ancestors into the interface table as well if you really wanted to without explicitly writing them down - you have the implement the methods anyway.

You are avoiding to answer the important question that is the reason why this does not work with COM interfaces.

My thoughts: 2. modify QueryInterface to take care of looking through the implemented interfaces if any of them inherits from the requested if it was not implemented implicitly - or simply add base interfaces to the implementing class - not a big deal fwiw. 3. what exactly does that mean? 4. reference counting issue - a procedure of object is just two raw pointers - how does that mix with interfaces - now if those COM-free interfaces would not have reference counting implemented the problem I described previously arises which will make them rather pointless.

Yes! In the COM implementation and it was carried over to Delphi as a feature to make it work.

What you describe is exactly what traits are in Scala. Well minus the fact that traits can even declare fields but when they always implemented by objects that would work as well - hence I would not call them anything like "so and so interface" - because while they might be similar they would be a completely different beast and not to be mixed with them. Anyhow it would come down to no proper way to cleanup those things - Scala and all other languages that have similar things use GC so you will not have any headaches about when something has to be destroyed. If you pass around your objects as traits/ninterface/whatever with the memory management we currently have in Delphi this will just an even huger pain than you already have if you mix object and interface references to classes that either implement reference counting or not. P.S. If you are interested how Scala implements traits: https://www.nurkiewicz.com/2013/04/scala-traits-implementation-and.html

"Native Interface" is a terrible name tbh - what exactly would be "native" about it that current interfaces are not. A look at other languages might be helpful to actually define clearly what your desired requirements are - for example traits in Scala.

According to that logic IFooBar must not be assignment compatible to IBar - but it is. Even the compiler knows about this because actually if you implement IFooBar and IBar into the same class without any specific method resolution clauses it puts both IMTs into the very same slot (IBar shares it with the IFooBar one)

There is nothing logical about it - as the previously linked article says:

@stk.List[stk.Count-1]

Yes - because try finally (not only the implicit! ones) are implemented poorly and result in trashing the return stack buffer of the CPU all the time: https://quality.embarcadero.com/browse/RSP-27375 @Attila Kovacs The difference between the two IsBreak versions is most likely related to branch prediction and the difference between a conditional forward jump typically taken and not taken - if you want to read more about it I suggest this rather in depth article by Matt Godbolt: https://xania.org/201602/bpu-part-one As for performance of this nested function I would guess it could run even faster when it would not access anything from the outside because that usually requires quite some stack lifting. And having to do that usually prevents the compiler to have more than one exit point as was mentioned before - if there are no registers to pop and that the compiler neatly puts rets in different places though - but I would guess you will not get around that for this function but probably around repeatedly accessing the LineBreak property and variables P2 and LineBreakLen

@Lars Fosdal Marketing drivel.

I can't see a situation where TArray<T> can have noticable overhead as it does not have enough stuff to be generated - what you demonstrated was using a generic class that has executable code and RTTI.

Not for TArray<T> but possibly for types with actual executable code - see my reply to Mahdi. The question was about TArray<T> where it does not matter at all rather than a few unnoticable microseconds at compile time. You are right however when talking about types that have executable code (and possibly a significant amount of typeinfo) as the compiler always emits all code of a generic type into each and every dcu that is using it as in your example with Unit1 and Unit2. However it does not need to emit into Unit3.dcu because that one is just referencing the type that already fully resides in Unit2.

I think you meant to write: TItems = TArray<TItem>; Apart from not having to type the angle brackets anymore this is exactly the same type as TItems is just an alias for TArray<TItem>

Sounds more like you have some serious issue with your globals

Those languages to my knowledge don't also have something like the initialization part of a unit which might cause a chicken-egg-problem.

According to what Allen wrote in 2009 that is not true. If there is a bug with that please link to the QP entry and/or code to repro wrong behavior.

Simply, because it obviously was designed poorly and assumes that every individual installation is an atomic thing that needs the restart not allowing you to install a couple more and only then restart.

Only testing the code yourself will show but I can smell a potential memory leak due to circular references caused by anonymous methods and capturing of the IOmniTask within itself - nested anonymous methods can be a bit nasty sometimes.

Afaik the dialog used by Delphi is just what the winapi offers.

Give some more votes to https://quality.embarcadero.com/browse/RSP-16751 maybe we get it some day...

If the term pebcak is offending you must be new to the internet. I simply explained the way that always works for installing jcl/jvcl 1. The same as always - jcl\lib\d27\win32 or win64 and jcl\source\include 2. Yes, works JCL/JVCL setup issues are almost always a problem with not properly executing them or rather not having the latest jcl/jvcl sources or having some old stuff lying around. Maybe you did not update the submodule and are missing on the defines for 10.4 Also did you select both (10.4 32bit and 10.4 64bit)? And did not set the "Install selected only" checkbox?

Clearly you need to write your own WillRaise version that does not just swallow the exception but passes it on to the logger.

Clearly a pebcak. Just pulled the jcl repo, ran install.bat - it compiled the setup using 10.4 and then I installed JCL for 10.4 32bit and 64bit without a problem