[fpc-pascal] Question about interfaces and patch

[ml at brainwashers.org]

Quoting Thomas Schatzl <tom_at_work at gmx.at>:

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

it is for my other feature (converting interface vmt to original class vmt, it
was said that some com or corba objects don't have asociated object, so you
can't transfer to classes vmt because class object is not present. with
IClassUnknown I know that interface is completely handled by fpc. 

this is needed for support for, here you need run-time calculateded interface vmt
property SomeList: TSomeList read FSomeList implements ISomeList;
- This is present from delphi 4, but not supported in fpc
as for the other idea I have in mind
property A: integer read object write object;
property or function aliases aren't in my interests so they probably won't be
done, at least by me), 
i don't want to break any incompatibility with any fpc compilable source.

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

corba will have its time, but first i'd like to finish features more needed by me
 
> 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 { ... };
> 

I know that, but nor Delphi neither fpc support MI. I'd like to implement it as
add-on patch (when finished it will be downloadable from my site). Somehow got
the feeling that people don't wan't more, even though it doesn't break anything. 

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

Yes there is a problem. It looks like some people would like to crucify me
because I try to think out of borland. Even though I specified that this will be
outside patches (can be included if wished) and they won't break anything. 

And second problem is that fpc does interfacing the wrong way. Interfaces stack
vmt one on another and report offset of children when inheriting, which is
sensible when you talk classes, but unfortunatelly this is plain wrong if you
want to do multiple interfaces.

multiple interfaces don't stack vmts (actualy in any other open source language
they don't do that. I don't know for delphi though). They just pose another vmt
as dependancy, because there is no overloading and no virtualizing.

having (for example down here)
IA > function A: integer;
IB > function A: integer;
IC > function A: integer;
ID > function A: integer;
doesn't request four implementations in class. So every vmt is self sustainable.
It just has to be posed as needed

MI just poses list of interfaces and his own functions and properties.

in simple logic

type 
  IA = interface(IB, IC, ID)

Correct MI handling is like this: IA definition has specified only his own
functions in his vmt + additional vmt needs. But when object does

type
  TA = class(TInterfacedObject, IA)

this just gets translated to

  TA = class(TInterfacedObject, IA + what IA needs)
  TA = class(TInterfacedObject, IA, IB, IC, ID)

when calling Support for MI.

  1.Check support (IA) 
  2.Check is IA has needed interfaces
  3.Check support for every needed interface in IA list
  4.If all conditions satisfied then true 

> 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()? =)
> 

didn't look at that, does fpc have 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.
> 

i searched but i can't find rfc for calculating guid. md5sum should probably suffice

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

yeah, I knew it was bad, but it was a temporary quickfix solution. that's why i
was asking, 128/bit md5 sum from "unit.interfacename" should probably do the trick

> 
> But all this is only my personal opinion about this issue.
> 
> 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/)