[fpc-pascal] Question about interfaces

[Marco van de Voort]

> Seems a bit sad to me that, I didn't get answer to "what I really asked"
> but a lot of flaming posts about one btw. in my question, even subject
> says "Question about interfaces" and not "Question about operators". 
> 
> 1. Couldn't interfaces support blind properties (specifying only read
> write capability)? Without having to specify function and procedure for
> writing. Property access varies from one interface inheritor to another
> and interface cares only about read write ability of property. Blind
> properties could be applied without any loosing of compatibility. And
> demands a whole lot more code in the way as it is applied now.
> 
> What you would get from blind interface properties?
> - Lot less code.
> - Smaller more readable interfaces
> - freedom of property implementation in classes

This doesn't sound bad, but there is an implementation problem I think. The
idea itself is sound, an interface is a contract only and how a property
is implemented is a implementation detail.

However the problem is that one must be able to access the property give
only the interface definition. Keep in mind that a property can be both a
field and calls to getter/setter functions, and also that a property is only
a language construction. In the final code, a direct reference to the field
or getter/setter is done.

In this light, decoupling a property poses a problem; if the compiler has

var x : ISomeinterface; // has a  blind property someproperty

begin
  x:=getintfromsomewhere;
  writeln(x.someproperty);  
end; 

how do I know what code to generate for the property?

> 2. Question about operators was about YES: "existing" and YES: "pascal
> standard" "is" operator and interfaces. Instead of needing to write
>  
>   if Supports(obj, ISomeInterface) then
> 
> wouldn't it be nicer to be able to write
> 
>   if (obj is ISomeInterface) then
>   if (obj is [ISomeInterface, ISomeOtherInterface]) then

I have no idea, but I fail to see the point a bit (this isn't a much
used construct), but it could. 

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.

In seven years of FPC work, I pretty much came up with one extension
(properties at the procedural level, and while useful, not the most
interesting or timesaving one.)

> Which is completely what you all said. I just noted that standard pascal
> operator "is" does not exist for interfaces.

There is no such thing "is" is a Delphi extension. A later one even.

> Array checking would be
> nice if one uses fine grained interfaces and therefore usually needs
> more than one interface for one function

It's a set.
  
> 3. Interface multiple inheritance. Asking just for a reason why not, for
> sole curiosity.

Interfaces to my knowledge are contracts about sets of calls. More or less
function X is at offset y*4 or something like that.

If you create a new interface by multiple inheritance from both X and Y each
with 4 methods, you get a new interface Z with 8 methods.

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.

> I solved that for my self with macros.

Macro's are no solution, but a hack. 

>  Just as I implemented foreach(). 

Eeeuw :_)
 
> What are benefits of interface multiple inheritance:
> - No monolithic structure
> - Fine grained interfaces (smaller, easier to read)
> - Lot less code duplication

All a bit vague. Could you back these up with real examples?

(p.s. Interfaces have no code. That is pretty much their definition :_)