[fpc-pascal] Question about interfaces and patch

ml at brainwashers.org ml at brainwashers.org
Thu Mar 24 02:20:30 CET 2005

Quoting Michael Van Canneyt <michael.vancanneyt at wisa.be>:

> On Wed, 23 Mar 2005 ml at brainwashers.org wrote:
> > Quoting Marco van de Voort <marcov at stack.nl>:
> >
> >>> On Tue, 22 Mar 2005, ml wrote:
> >>>> // than one interface
> >>>>  a := (object as IA); // correct
> >>>>  b := (object as IB); // returns pointer to the first interface
> > vmt=IA
> >>>>  c := (object as IC); // returns pointer to the first interface
> > vmt=IA
> >>>> // there's no way to do again it's like direct call to exception
> >>>>  obj := a; // returns pointer(obj) + 12 ???
> >>>
> >>> This is nonsense. You cannot assign an interface to a class.
> >>> A class IMPLEMENTS an interface, it is not an interface.
> >
> > Ok, its nonsense. I said it already works with my patch, but I guess you
> > know it better. So my example down there doesn't work (with patch). You
> > should know.
> > I (; can't ;) transfer from one interface to other back to object and to
> > 3rd interface. I just imagine my results.
> Tell me, what is
>    obj := a;
> supposed to DO ? A class has a set of methods. Some of these methods form
> the VMT of an interface. What your code does, is say
> "don't use your VMT methods, use these instead' ?

Yes, exactly. I even provided test example at the bottom of my previous message,
where I transfered from class to IA, back to class and then to ID. And called
ID.D; And it just works (this is also nice start for blind properties
implementation, which now also became possible, since original vmt is now visible)

But, It should be used as

if (TObject(a).InheritedFrom(TSomeClass)) then begin
  obj := TSomeClass(a); // note that here obj is declared as TSomeClass
  // now safely use as this vmt

if SupportsInterface(TObject(a), IB) then begin
  ibvar := a;  // declared ibvar: IB
  // now safely use as this vmt

in perfect world "is" would return InheritedFrom or SupportsInterface result and
not actual class check, if true then all needed operations are satisfied. 

Now how it could be:
if (a is TSomeClass) then  // if "is" and "as" would be perfectly handled
  obj := (a as TSomeClass);
if (a is IB) then  // if "is" and "as" would be perfectly handled
  ibvar := (a as IB);
Now if someone could say that this isn't beautifull or readable

safetype checking MUST BE USED for Interface to (Interface or class) vmt
translation, as I specified above

p.s. At the bottom of the message I provided complete program for testing and
you ask me about the one I provided to show problems with current interfaces as
they are in fpc 1.9.8 (that was few messages ago)???? 

In virtual (virtual just as in trying to use as different type than one that was
passed) interface usage additional safety code is needed. And it is not even a
bit different than checking if pointer or class is nil before using it. As I
already said, pascal interfaces in current state are NOT usable, even := and
"as" are not treated consistantly (they should be otherwise "as" is rendered as
unusable because it almost always invokes exception *bad vmt is passed when more
than one interface is inherited in class). I have a few imeplementation

Virtual type access has its cost in speed but flexibility is a major boost. Have
an working implementation idea for multiple interface inheritance too, and that
one will just work too (ok, as soon as I find all the parts of code that need
patching, but solution patch (and I mean complete solution not hacked one)
probably won't be more than 40 lines long).

After all patches (vmt patch, blind properties, as and is, multiple
inheritance), interfaces could become as powerfull and beatifull as interfaces
should be. I think that cost of all patches will be about 100-150 lines long


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