[fpc-pascal] Question about interfaces
Marco van de Voort
marcov at stack.nl
Mon Mar 21 08:41:04 CET 2005
> Quoting Marco van de Voort <marcov at stack.nl>:
> > 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
> > 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.
> 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.
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;
for i:=0 to n-1 do
for j:=0 to n-1-i do
if array[j+1] < a[j] then
The trick is that above code is general, except for the type, since array
access, the compare, and the swapping depend on the type.
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
More information about the fpc-pascal