[fpc-pascal] Question about interfaces

[Marco van de Voort]

> Quoting Marco van de Voort <marcov at stack.nl>:
> 
> > begin
> >   x:=getintfromsomewhere;
> >   writeln(x.someproperty);  
> > end; 
> > 
> > how do I know what code to generate for the property?
> > 
> 
> 
> Shouldn't direct access to object and resolving object property be involved here
> when dealing with interface property and not pointing to interface functions and
> procedures? 
> You have the pointer to object, so you have the pointer to its vmt

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.

> Shouldn't property be accessed like that in the real world?

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)

> > Being a compiler developer is not sitting on a table and thinking up all
> > kinds of interesting new extensions. I know some of the perl/python freaks
> > seem to do it like that, but they seem to be engaged into some who can
> > write the shortest and most unreadable code contest.
> 
> Not that I try to lower your status or status of fpc, I repect everybody that is
> able to maintain project as large as this, but
> 
> Not always, if competing who will do more then yes. But then there could
> be a lot of good new things suggested. Users can have good ideas, look at
> inkscape for example. Every suggested idea (people in mailing lists
> suggest different variantions or ) goes to discussion and they discuss if
> feature should be included and how it should be included.

Yes, that's what that is? And of course a feature is not auto included up
front, and all sides have to be carefully weighted. Moreover, in a compiled
language, there is much less possible.
 
> I don't believe that living under borland shell is the way to go. This
> said is just like you would said that there's no world beside borland and
> all features not implemented in borland are not good.

The accent is Borland. Other features are added on merits, and they have to 
be real added value, not just a shorter notation, or something depending on
personal taste. 

> No invention, no progress. Maybe that's why Phyton has so many people.   Because
> people expect new approaches

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.

> > However Z can only be compatible with one interface, namely the one that
> > gets the first 4 methods. So if I create Z with first the 4 methods of X
> > and then those of Y, Z will be compatible with X (same 4 methods on the same
> > offsets), but not with Y.
> > 
> 
> Care to explain offsets here:
> IA = interface
> function A: integer;
> end;
> IB=interface(IA)
> function B: integer;
> end;
> IC=interface(IB)
> procedure C;
> end;

A 0
--- in IA only this is visible
B 4
-- in IB only this is visible
C 8

Now go to the MI example,  assume that C inherits from both IA and IB, and
IB not from iA

IA:
A 0

IB:
B 0  

IC: ?


> Don't take it so literaly. It's just that interface usage goes beyond simple
> logic. You have two possible implementation
> 
> - monolithic structure where interfaces express most of the object reflection
> - non-monolithic fine grained, which can be implemented in two ways
> 
> 1. Real, interfaces that have multiple inheritors can be inherited
> 2. Posibility of setting sets of combinations
> 
> Version 1 would be best, but as I saw version 2 is not so bad. When you
> use fine grained interfaces, you try to avoid interface inheriting
> completely (it would not make sense anyway). And use those sets in classes
> inheritance and functionality checking only.
> 
> On of my previous e-mails had simple macro solution which is more than
> satisfiable for version 2, except that its a hack and no solution

Still no idea what so ever. What can you do ?

> > >  Just as I implemented foreach(). 
> > 
> > Eeeuw :_)
> 
> I thought that at first too, yes. But after a while I started loving them.
> Working with 20-30 threads does that to you.

Do that everyday, never missed foreach.

> If foreach is carefuly designed then it can be threadsafe and balanced.
> Which you can't say for "for i := 0 to (Count - 1) do" if you code
> threaded environment.  Balanced enumerators reflect on changes in list.
> When my list deletes items in one thread all enumerators reflect to change
> and reposition them self accordingly.

So in short you say you use iterators on one spot. Mmany languages
have iterator systems, but most don't have the silly syntactic sugar foreach.

So in your case it is only short for

x:=startiter;
while x,iterateover do y;

> > All a bit vague. Could you back these up with real examples?
> 
> ok, here it one in c#, the only problem here could be that you would try
> to look at this from monolithic perspective. And notice how many times one
> could reuse those simple interfaces.  As soon as interface goes
> complex,... well there's no difference if you would use class.

So again it is actually only a shorthand notation for something that
can be done perfectly otherwise. (Write them out, and test all interfaces)

One can think up a terse short notation for _every_ construct there is, that
_somebody_ uses a lot, but it will only blow up language and runtime, and eat
up developer time.

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.

> Its just like glade or delphi interface designer. Glade is harder to figure out
> but its bulletproof, while delphi is simple but at the same time almost
> unqualified for its existance. 
> I just change font size and almost all delphi windows go broken (change the
> language, well how many labels gets too long and get covered up with controls).
> Glade does not 
> suffer from this effects, form is always as it should be. But it had to be
> planned much more than delphi form was.

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.
 
> And by the way, about chess example that was here
> 
> One guy didn't succed and this is the reason why no one should try something new
> ever again??? Shouldn't everybody make suicide too, just because one guy didn't
> succed in his life, nobody will?

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.