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).
[EMAIL PROTECTED] schrieb:
ml schrieb:This is doable, patch can contain both with compiler directive for selection
Hmmm, Delphi gives a compile time error if "as" is used on an interface [...]
(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
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
