[fpc-pascal] Question about interfaces

[ml]

> > Quoting Marco van de Voort <marcov at stack.nl>:

Like first, I wouldn't like to spam this mailing list about interfaces.
Can I contact you directly or somewhere else?

I would like to try to patch some things but I would probably have few
questions how to implement it to satisfy everybody, or the general
interfaces idea and implementation.

One major problem with interfaces is class <=> interface <=> class
inflexibility and this is the root of everything.

imagine interfaces declared IA, IB, IC, ID, and all standalone
TA=class(TInterfacedObject,IA,IB,IC);

var
  a: IA; b: IB; c: IC; d: ID; obj: TA;
begin
  a := obj; // result is pointer(obj) + 12;
  b := obj; // result is pointer(obj) + 16;
  c := obj; // result is pointer(obj) + 20;
// Following is nonsense, its just like "as" would be direct 
// call to exception if you try to use class that inherits more 
// 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 ???
// because of the previous offset problems calling both next 
// things is impossible (or better to say it is always false), 
// this is true only when IB would be inherited from IA
  if Supports(b, IA) then
    IA(b).something;
  if Supports(b, IA) then
    a := b;
end;

I have a working idea how to solve this problem (without loosing any
compatibility or any drastic change, in fact changing very little) but I
would like to hear your opinion on my proposal first. Change is fairly
simple, and after my change everything here becomes possible and safer.
And since every problem I named here produces either compiler error or
exception now already, there would be no difference if somebody would
use it incorrectly.

  a := d; // produce exception when assigning

or used correctly, which leads to much safer interface code, where
runtime is much more flexible
  
  if Supports(a, ID) then
    a := d;

On Mon, 2005-03-21 at 08:41 +0100, Marco van de Voort wrote:
> > 
> > > 
> > > Afaik not, you have a pointer to an interface table, And even if you can get
> > > to the object vmt from there, you don't know anything about it. interface is
> > > all about information hiding. It might not even be a proper Pascal object.
> > > 
> > > No, the whole idea of property is simply to easily declare iDE editable
> > > values. As nice added extra: the ability to change from direct field to
> > > getter/setter based access easily. (read: without changes in the calling
> > > code)
> > > 
> > 
> > Could you explain this extra a little more?
> 
> RTTI (introspection in Java lingo) is generated for properties. This is used
> by the IDE/Rad, but the whole principles are general.
> 
> > > Nonsense. Python and perl etc were launched in the bubble era and are still
> > > floating on that capital. However there is a lot of hype and tinkering,and
> > > little real work done in it. Of course, enough hype will ensure that some
> > > stuff will be done, but I don't really have the feeling that the hype and
> > > actual serious use are in any sane proportion.
> > > 
> > 
> > Little work? Guess we live in different world
> 
> Yup.
> 
> > > 
> > > IB:
> > > B 0  
> > > 
> > > IC: ?
> > 
> > Couldn't this be solved with offset?
> > IC > IA=0,IB=+IA
> 
> No. Keep in mind that I can assign IC to a variable of both IA and IB. And
> those specify their first method at 0.
> 
> In this case setting IB's 1 st method to 4 would solve some stuff, but that
> is not a generic solution.
> 
> In general this _is_ the multiple inheritance problem, together with
> initialisation order and what you do if you have methods with the same name.
> 
> Interfaces is simply a basic form of MI modeled to avoid the worst pitfalls,
> and now you are trying to bring it back via the backdoor.
> 
> > and how does the object do that?
> 
> A table for each interface I guess. And, more important, there are no
> relations to keep between the interfaces IA,IB,IC in below example.
> 
> > TC=class(IA,IB,IC)
>  
> > or if I understand it correctly object has this solved in vmt, and interface
> > posseses no internal vmt
> 
> There parts of the per object tables that deal with interfaces. I assume
> an interface reference is a reference to this?
> 
> > > 
> > > To give you an counter example: Personally the only thing currently on my
> > > wishlist are generics. But that is a bit too hefty to implement shortterm.
> > > 
> > > Why generics? They really allow things that can't be done:
> > > - typesafe containers.
> > > - parameterising algoratims with types in general.
> > > 
> > 
> > generics in pascal?
> > you lost me there. Generics are nothing but typesafe declarations, used in
> > higher languages like c# and java.
> 
> This is not true. C# and Java only got them in their last iteration. Ada and C++
> are much older implementations, and they don't have the stuff below.
> 
> > pascal does not suffer from  box/unbox timing
> > in fact pascal does not support box/unbox
> 
> No. It can be used for this (it is part of the typesafe container stuff),
> but one can also parameterise code.
> 

this is nice. boxing/unboxing and then typed unboxing :D

> The token example is a generic sorting routine. E.g. the bubble sort:
> 
> procedure bubblesort<T>(a:array of T);  // T is the type
> 
> var  tmp : T;
> 
> begin
> for i:=0 to n-1 do
>   for j:=0 to n-1-i do
>    begin
>     if array[j+1] < a[j] then
>       begin
>         tmp:=a[j]; a[j]:=a[j+1];
>         a[j+1]:=tmp;
>       end;
>    end; 
> end;
> 
> The trick is that above code is general, except for the type, since array
> access, the compare, and the swapping depend on the type.
> 

in c# this is solved trough operators, one has to define them for a new
type. And I like it

> Generics allow this kind of code to be parameterised by the type and
> instantiate the code per type.
> 
> Reasons can be:
> - typesafety (which can also save you autoboxing)
> - speed (typical example above works with compare/swap as procedure vars
> 	with call overhead and bad optimisation)
> - reuse of code in general.
> 
> > > It is also significantly more heavy weight. That is not necessarily bad,
> > > it is just what you choose for. Delphi has enough room to implement
> > > frameworks on top of it. And not only for this solution. Moreover one
> > > can take over the designer via the toolsapi without access to delphi.
> > 
> > I was pointing out how bad default windows interface is
> 
> It has flaws, certainly. However I have not seen something that has no
> downsides. A lot of interfaces that try to do it all are unbearably slow.
> 
> I e.g. checked out OS X's COCOA a while back, and all the Objective C runtime
> interfacing also doesn't really feel "easy".
> 
> > > It will be interesting to see your patches then. Maybe I'll change my
> > > opinion
> > > if I have played with your fork of the code.
>  
> > Fork? if there would be patches they would be insignificant, but since I'm
> > inside of tech preview for my project this would mean that fpc would go
> > out of race for this project before I would started patching either
> > solution is simple and supported directly or not
> 
> Well, I doubt developers will abandon their schedules to implement features
> like this.
> 

Never asked for that (I'm more like do it alone and don't whine type),
maybe I said it a bit strange (English is not my native language). If
simple patches are possible, then I would like to try that, but forking
already working solution just because of me, would be unfair and too
hard for me alone. If forking would be the answer, then I would probably
choose other language.

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