[fpc-pascal] Question about interfaces and patch

ml at brainwashers.org ml at brainwashers.org
Sat Mar 26 01:36:38 CET 2005

Quoting Thomas Schatzl <tom_at_work at gmx.at>:

> Hello,
> ml schrieb:

> Hmmm, Delphi gives a compile time error if "as" is used on an interface 
> without GUID, same for support()... since both use the interfaces IID to 
> query for existence of an interface (either directly or via 
> QueryInterface of IUnknown).

This is doable, patch can contain both with compiler directive for selection
(ok, usage of compiler error is not done yet). One other possibility is checking
some IClassUnknown (inherited from IUnknown) support and auto assign guid (at
least if not defined in interface) to it. If it is not, then interface is either
COM or Corba and should be left alone so that interface doesn't break anything.
If interface is derived from this IClassUnknown, then this means that: 
1. class object is present
2. not corba or com

In fpc sources there's a comment
if guid is 0 then corba_interface otherwise com_interface (I don't have my
notebook here so this is not copy pasted from source, just the meaning). Are
corba interfaces really guid 0 (if that would be the case then support and as
wouldn't work on corba interfaces in Delphi), or is that comment just outdated?

> > Any better suggested approach? (Second possible solution would be
> > implementing some other checking that's invoked if guid is 0) I am not
> > familiar with what guid would be (I suspect that it has some higher
> > meaning in windows, because all windows interfaces are specified with
> > guid, now even m$ stopped using specified guid in .net), so I would
> The GUID (=UUID) uniquely identifies a COM interface. A .net interface 
> is not a COM interface, it's more a language construct like in Java.
> By some wrapping any(?) .net interface can be used as COM interface 
> afaik (and the other way round) though.

Yes, but COM object must load .net dll and create new interface

> .net provides more advanced means of querying run-time type information 
> than the ones available in Object Pascal, e.g. it likely does not need 
> to rely on a GUID for these types of operation, so there's no need to 
> specify this by default.

No it doesn't. Nice example is using CILC (exists on mono) on dll that provides
interfaces. CILC produces c headers and library for accessing .net dlls. don't
know if it works ms .net (it probably should).

> Btw, to implement unnamed properties of (non-COM) interfaces (as the one 
> available in objfpc mode) there's imo need for more sophisticated rtti; 
> e.g. so that this would work, you'd need a way to query the read and 
> write methods of the particular class of the instance and call them.
> Neither querying of properties nor getting info on the read/write 
> methods of properties is possible atm since Object Pascal does not store 
> this info anywhere by default afaik (for all visibility types of 
> properties, for all Pascal objects).
> [Maybe I'm wrong, I'm not so into rtti]

It is doable and in my plan. But I suspect it will just stay my own patch for me
and whoever wants it (as some others interface patches of mine, like multiple

> > appreciate some help by suggesting. And yes, this is a bug not a
> > feature.
> Either automatically create a good GUID for the interface (there should 
> be a CreateGUID() method in fpc), or error out like Delphi (to be
> compatible).

and good guid would be? If I remember correctly I saw GUID calculator for Delphi
but I don't remember where and if method implemented was official way of
calculating GUID (if this exists).
for now I just assign max possible interface and decrement for every type.

> Regards,
>    Thomas


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

This mail sent through Horde-Toaster (http://qmailtoaster.clikka.com/)

More information about the fpc-pascal mailing list