[fpc-pascal] inherited interfaces not seen by queryinterface / supports

[Graeme Geldenhuys]

On 2016-10-27 03:47, Graeme Geldenhuys wrote:
> Again, I don't know why it is done like this, and works very different
> to class inheritance. Delphi 7 works exactly the same in this regard.
> Maybe somebody with more knowledge on the subject could shed some light.

I did some quick internet searching. According to Danny Thorpe (an ex
Borland employee I believe), the reason Delphi works so "weird"
regarding Interface Inheritance, is because Delphi is very Windows
centric, and initially Delphi Interfaces were COM compatible interfaces.
Microsoft made some screw-up in COM, and Delphi followed suite.

  http://stackoverflow.com/a/4380371


"The reason is because COM and ActiveX allow an implementation to
implement a descendent interface (your IChild) but deny the ancestor of
that interface (IParent). Since Delphi interfaces are intended to be COM
compatible, that's where this goofy artifact comes from." -- Danny Thorpe


Now my question to the FPC developers are... For a long time now,
Interface support does not always mean COM or ActiveX support, so why
still does FPC do the same as Delphi? And even worse, why does this same
behaviour happen in FPC's CORBA style interfaces - which has *nothing*
to do with COM or ActiveX???

Here as a FPC (CORBA style interfaces) example of the problem with
Interface Inheritance.

============================================
program Project1;

  {$mode objfpc}{$H+}
  {$interfaces corba}

uses
  SysUtils;

type
  IOne = interface
  ['{32271879-1C00-4A02-A9C0-6948844028D6}']
    procedure One;
  end;

  ITwo = interface(IOne)
  ['{F3027177-6638-4984-B842-7D4E70299056}']
    procedure Two;
  end;

  TMyObject = class(TObject, ITwo) //  <<---- IOne is not specified
  private
    // IOne interface
    procedure One;
    // ITwo interface
    procedure Two;
  end;

procedure TMyObject.One;
begin
  writeln('One');
end;

procedure TMyObject.Two;
begin
  writeln('Two');
end;

var
  o: TMyObject;
  i1: IOne;
  i2: ITwo;
begin
  o := TMyObject.Create;
  if Supports(o, ITwo, i2) then
    i2.Two;
  if Supports(o, IOne, i1) then  // this is never true
    i1.One;
  i2 := nil;
  i1 := nil;
  o.Free;
end.
============================================


In the Stack Overflow link I posted - further down the page - a person
named Jasper mentions that in is QueryInterface implementation bug where
QueryInterface on checks for valid Interface signatures in the top level
of the interface hierarchy, and doesn't actually check for inherited
interfaces.  Anyway, read Jasper's comment to see his exact words.

   http://stackoverflow.com/a/39496815


If nothing else, surely FPC's CORBA style interfaces should not
implement the COM style interface bug?

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp