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@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
