> > Quoting Marco van de Voort <[EMAIL PROTECTED]>:
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@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
