[fpc-pascal] Question about interfaces and patch

Thomas Schatzl tom_at_work at gmx.at
Sat Mar 26 18:00:34 CET 2005


Hello,

  note in advance: if I mention CORBA interfaces, I actually mean "CORBA
style" or Java/.net like interfaces (which are not real CORBA interfaces
anyway) in the following (too lazy to do a search&replace or find
another term).

ml at brainwashers.org schrieb:
>>ml schrieb:
>>Hmmm, Delphi gives a compile time error if "as" is used on an interface 
>> [...]
>>
> 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. 

This check for COM-interfaces could be done on compile time saving
runtime (and code, and... :) if supports() or as is used in the code. Or
simply automatically assign a reasonable GUID for every COM interface
(probably easier =)

I don't know if checking for some class IClassUnknown is actually
required...
Maybe handle operators for CORBA interfaces completely differently (the
compiler already recognizes the type of the interface at compile time
from what I can see from the compiler code).

E.g. avoid using standard QueryInterface() (which may not be available
for CORBA interfaces anyway) for this type and completely rely on other
means for that.

But this would require more compiler tinkering.

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

This is not true, since COM interfaces which don't have a GUID assigned
also have the default zero GUID.

But interfaces support seems to be at least partially broken for both
COM and CORBA interfaces, especially the supports() and "as" operators
(in the 1.9.8 compiler).

>>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
> inheritance).

Actually I'd love to see a more complete RTTI in Pascal (say, e.g. in
OBJFPC mode), not minding the increased binary sizes (maybe optional).
Although I don't need it very often, the introspection information
offered by Delphi is quite limited (e.g. exactly to the explicitely
published things which Borland needed for the IDE).

Btw, MI for interfaces is completely fine for Corba interfaces, I had a
peek at the spec (well, I needed it for other things too ;). E.g. it's
completely fine to specify this:

interface A { ... }
interface B: A { ... }
interface C: A { ... }
interface D: B, C { ... }
interface E: A, B { ... };

[From the Corba core spec, v3.0: interface declaration, pg. 3-23]

Since an interface is only a specification without implementation I
don't see any troubles concerning multiple inheritance as pointed out in
another message of this thread (going towards Java/c# like interfaces).

Some additional safety things should be put into place to not allow
mixing them though (e.g. similar to not allow mixing old style objects
with new style classes).

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

Ones created by CreateGUID()? =)

> but I don't remember where and if method implemented was official way of
> calculating GUID (if this exists).

I think there's an RFC out there to calc UUIDs (which is the same as a
GUID) for DCE/RPC or so. But as far as I'm concerned it should be fine
to rely on the OS for that.
Usually part of the RPC implementation - for Windows I know that RPC is 
used in any version. In case of some Unix (or other OS), if the required 
libs are not available (can't really imagine that there's no standard 
RPC implementation for that), use a good 128 bit random number from 
somewhere.

> for now I just assign max possible interface and decrement for every type.

This is bad, because this GUID is stored in every ppu file for the types
too. So if you use some external lib they will certainly clash (actually 
I think they already do, probably making using interfaces quite 
interesting for the person who debugs that code =)

But all this is only my personal opinion about this issue.

Regards,
   Thomas





More information about the fpc-pascal mailing list