[fpc-pascal] Question about interfaces and patch

[ml]

On Thu, 2005-03-24 at 21:21 +0100, Michael Van Canneyt wrote:

> OK, now I see where you're going.
> 
> Your last sentence means: I want DoReport to accept only an 'IReportable'
> But at the same time, your code is checking that behind 'IReportable'
> there is also an 'ILogged'.
> 
> I find this a bit contradictory; If you pass an TInterfacedObject, then
> you can check for as much classes or interfaces as you want.
> The code remains the same. But this is not a principal question.
> 

Since you agree with "is" and "as". this one is solved too. Maybe you
don't see benefits, but "is" and "as" are the only conditions to be able
to do what I want. So I guess this doesn't need to be discussed anymore.

> More important is: what happens if IReportable is an interface obtained
> from Windows ? How can you tell whether an interface comes from a Pascal
> class, or was obtained from a Windows OLE or ActiveX server ?
> There may not be a a real class behind IReportable.
> You can construct IReportable interfaces on the fly.
> (OpenOffice does it, and I think some SOAP implementations as well)
> 

That's what I was asking for. I'm not a windows person and I don't know
what problems one could face there. 

One solution I see is:

Implementing Me in descedant of IUnknown in IClassUnknown and if
interface does not support IClassUnknown instead of calling Me: TObject
would just return nil. Meaning class vmt access is not possible and all
interface checking is solved trough QueryInterface. After "as" and "is"
recognize if interface is classed or not, all problems you named should
go away. I maybe have a better way, but I would like to test that one
before anyone would start to play nitpick on it.

My question here is: Can I get a simple example of usage to see a
problem with windows interfaces, it'll be easier for me to discuss it
then?

> I think the properties are needed, to remain compatible with COM
> interfaces, which only have methods, I think CORBA has this restriction
> too; They don't have 'properties'.
> 

Agreed, but then again new property implementation doesn't exclude old
one. Just as 
procedure ... of object; 
here could be
property ... read object write object; // or something like this
or 
property ... read CallFunc write CallProc;

So if it doesn't break compatibility, what else could one expect
Here (word) object would just relink property on creation to the vmt of
original class (see comment down on not breaking OLE or ActiveX).

> After all the discussion, I see 2 real improvements:
> - To be able to use 'Is' operator  on interfaces.
>   (so without the need for 'Supports')
> - Use 'as' on interfaces. (But this should be possible as in Delphi)

I'll test Delphi, but I own v.5 (and have yet to set one windows box to
test on). Will this do?

> 
> As for querying the class behind the interface: first you need to answer the
> windows problem.
> 

As soon as I finish my patch for "as" and "is" I'll implement it so that
it will handle distinction between IUnknown and IClassUnknown (if
needed, as soon as I get example to test on, I'll know what to test for,
I'll try to look for some ActiveX or OLE example, but I know only where
to find Delphi stuff, will testing on Delphi examples suffice?) and send
patch here.

ml

> Michael.
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal