[fpc-devel] interfaces / inheritance / again -x

[Michael Van Canneyt]

On Mon, 2 Feb 2026, Martin Frb via fpc-devel wrote:

> On 02/02/2026 20:48, Michael Van Canneyt via fpc-devel wrote:
>>
>> Are you deliberately trying to shoot yourself in the foot here ?
>> (better your foot than my foot obviously...)
>
> Well, the simplest would be
>
>    generic TGen<DATA>
>
> no constraint, I can pass in whatever, and if it has the methods, then 
> good ... (or well...)
>
> But, that feels more like risking my foot. I quite prefer if I can give 
> a constraint, and if the compiler will know earlier what the generic is 
> about.
>
> I have a list. Well several lists. They share some functionality.
> But I can't just pack it into a base class.
>
> For once, at least in some parts of the code, the list will only be 
> known as "interface".
>
> The lists have different item classes too.  So now I thought I write a 
> generic that implements the shared bit.
> Actually the shared bit is in another class, that accepts the list as 
> argument. A worker class, if you will.
>
> generic SharedBit<_BASE, _LIST, _ITEM> = class(_BASE)
>   procedure ProcessItem(Itm: _ITEM);  virtual; // called by DoFoo
>   procedure DoFoo(List: _LIST);
> end;
>
> procedure DoFoo(List: _LIST);
> begin
>   ProcessItem(List.Entries[i]);  // Entries must return the specific 
> interface
> end
>
> ProcessItem must have the subclass, or at least the more specific interface.
>
> And yes, I could add to the interface
>   function GetObject: TObject
> and then type cast that.
> That feels like a bandaid.
>
> Since I do have some code that has the list as interface, the simplest 
> is that all code that does SharedBit uses the interfaces.
> (Well, yes, leave away the constraint, and I can specialize for either 
> class or interface)
>
>
>
>
>
>>
>> I assume this should be:
>>
>> property Bar: TBar read GetBar;
> yes
>
>
>>  property Bar: TSubBar read GetSubBar;
>>
>> property overrides exist, but they must keep the same type, they can only
>> change the specifiers. So I don't think this will compile. If it does, it
>> is probably by accident.
>
> It does actually compile.
>
> And on classes, properties can be reintroduces with any changes possible 
> (wouldn't necessarily do but works)

Yes, I forgot, Delphi allows this. It's a redeclaration, not an override.
(I always thought that was a bad idea)

Well, you have your answer. It compiles and probably should compile,
at least in mode delphi.

Whether it is a good approach, there we probably differ in opinion :-)

Michael.