Leaderboard

For those of you who are more interested about the differences in class vs. interface inheritance, here is a transcript from several live chats with the founders of Delphi: http://edn.embarcadero.com/article/20384 For those that don't want to read all (but it intersting anyway) here is the gist from Chuck Jazdzewski :

I will start with a bit of history. The Original Code is based on mwCustomEdit.pas by Martin Waldenburg, a great programmer. The key feature of the editor was fast syntax highlighting. This was more than 20 years ago. After a split of the community the SynEdit project was formed maintaining some of the key features of mwEdit. Over the years some of the best Delphi programmers contributed to the project. The list includes for example Gerald Nunn, Eric Grange, Jordan Russell and many many others. Flavio Etrusco added word wrap and Maël Hörz added unicode support (but in a rather idiosyncratic way). However the project management was very weak and the code gradually became very hard to maintain and improve. It aimed to support very old Delphi versions including Kylix and the code became full of IFDEFs and patches without an overall coherence. An early fork of Synedit is part of Lazarus but the two development efforts have diverged a great deal. When Embarcadero introduced the GetIt package manager they asked Roman Kassebaum to produce a version of SynEdit for GetIt. Roman did a general code cleanup removing support for early Delphi versions and Kylix (Turbo fork(s)). I have added support for code folding (the first major new feature for years) to both the Turbo fork and the main Synedit repository. However the Turbo fork(s) were not actively supported or developed beyond recompiling for new Delphi versions and the main Synedit branch was too hard to work with, hence the creation of SynEdit-2 as a fork of Turbo SynEdit. Main new features in SynEdit-2: Replaced SynRegExpr with the built-in RegularExpressions Move/Copy Line(s) Up/Down commands as in VS Code Delete Line command should work with multi-line selection Handle triple and quadruple clicks for selection Triple click and drag should select lines Double click and drag should select whole words Support OLE Drag & Drop What are the key features missing in Synedit: Better Unicode handling: Better support for wide characters e.g. Chinese ideograms (爾雅爾雅爾雅爾雅) Support for surrogate pairs (two widechars correspond to one glyph) Combining characters (e.g. Åström ḱṷṓn) Multi-cursor and multi-selection editing as in VS Code. When these features get implemented I think SynEdit will become comparable to some of the best editors around. But both of them require major rewriting of the code. Work on the second is well advanced and the unicode work is in the planning stage. Of course it is your choice as to which version of SynEdit to use, but if anyone wants to contribute to the development you are very welcome.

There is no proposal - there is just a "it would be cool if" without any actual suggestions how something can be achieved. I asked a couple of questions but they have not been answered (or I missed those) that are important to decide if something like event<->interface method binding can be achieved and how it would look like. Currently any assignment of interface methods to an event would break reference counting similar to how anonymous methods can't be assigned to an event. One is a managed type, the other is a record with 2 raw pointers. Now we could all list stuff that would be cool to have without actually evaluating if that is technically possible - but to me that would be just a waste of time I could spend more productive.

Hi there, Is anyone aware if Andreas is working on an updated version of it's wonderful tool? Thanks Stephane

Not the cause of the leak, but each of those calls to TSomeObject.Create needs to be protected in a try/finally

We're missing a main point: COM rules doesn't apply here The proposal is not about changing the current interface implementation; that one is fine for COM, and for that same reason is not as good as it should be just for decoupling under Delphi, as it just can't implement some every-day features we do have on real life code (ej. Event methods) The proposal is about having a new and independent breed of interfaces, able to implement the needs of current Delphi So we forget all and every bit related to COM, and keep the concept and how we Delphians would expect it to work So we expect using it with generics, and be able to use interface methods as class methods

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

Do you have any sources for this bug in COM or can you explain what bug is? Edit: Never mind. You just did.

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.

Thank you! This is in line with my understanding of the rules of COM. It seems that, unlike Kaster (it's a bug, it's a bug), Chuck (it's by design) actually read the books.

Why would you need a GUID if this is supposed to be "COM free"?

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

Free is implemented as if Assigned(Foo) then Foo.Destroy; so those if statements in the previous post are pointless. Call Free unconditionally.

Ok, no "for" loop, no "xor" etc.. which hides implementation details on Char, and reverted back to text=LineBreak delivers 1 empty string for compatibility reasons (original TString / .Split(), etc...) procedure TStringList.SetTextStr(const Value: string); var P, P2, fc, Start, LineBreakEnd: PChar; s: string; LineBreakLen: integer; LLineBreak: PChar; begin BeginUpdate; try Clear; P := Pointer(Value); if P <> nil then begin LLineBreak := PChar(LineBreak); LineBreakLen := Length(LLineBreak); if LineBreakLen > 0 then begin LineBreakEnd := LLineBreak + LineBreakLen; fc := LLineBreak; Start := P; while P^ <> #0 do begin while (P^ <> fc^) and (P^ <> #0) do Inc(P); if P^ <> #0 then begin P2 := P + 1; Inc(fc); while fc^ <> #0 do begin if P2^ <> fc^ then Break; Inc(P2); Inc(fc) end; if fc = LineBreakEnd then begin SetString(s, Start, P - Start); Add(s); P := P2; Start := P; end else Inc(P); fc := LLineBreak; end; end; if P > Start then begin SetString(s, Start, P - Start); Add(s); end; end else Add(Value); end; finally EndUpdate; end; end;

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.

I'm not aware about Scala but is this like what java does with default implementation for interface ?

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

You are correct: type IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; IFooBar = interface(IBar) ['{F99BAE4A-6612-4714-96B4-237763239C7F}'] end; type TFooBar = class(TInterfacedObject, IFooBar) end; procedure test; begin var FooBar: IFooBar := TFooBar.Create; var Bar: IBar := FooBar; end; ...but as we already know... var FooBar: IFooBar := TFooBar.Create; Assert(Supports(FooBar, IBar)); ...will fail, so there's a bug somewhere - or at least a really bad inconsistency. Supports just does a IUnknown.QueryInterface which ends up in TObject.GetInterface. The assignment on the other hand just copies the pointer and calls _AddRef. From my understanding on what interface inheritance is in Delphi, Supports() is correct and the compiler is wrong but there are obviously different interpretations of this.

"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)

But it isn't true. The IFooBar interface inherits the methods of IBar - at compile time. The implementing object doesn't inherit the contract that it must implement the IBar interface. I'm not convinced that John Kaster knew what he was talking about when he wrote that. I mostly included the link because it seems to be the earliest mention of the feature. The limitation as-is matches my recollection of "the rules of COM" but I could be mistaken. I'm not up to reading the COM bible again just to find out. It was hard enough the first time(s).

I totally understand, but some eye candy just wont work. And sooner or later some other stuff will follow. This discussion is as old as Windows itself. It used to be "my customers only run DOS" then became "my customers only run 16Bit Windows" over to "my customers only run WinXP" to what we have today. Someone in that story has not learned, and should be beaten with a set of Windows installation floppies: Hardware manufacturers that create one version of their controlling software and never update it, or for an ungodly price. We could break our ears and keep our software running on DOS, or just inform the customers and let them wise up and do a pitchfork and torch run on their machine manufacturer. After all, it is your hide they'll be after if something wont work because their system is outdated - not that this is the case right now.

As far as I know, he does not have a current Delphi license any more and needs the community edition of 10.4 before he can even start working on it.