The documentation simply states “no”, without explaining why.
Luckily, there is [WayBack] David Heffernan at [WayBack] Delphi interface generic function – Is there a work around? – Stack Overflow
Interfaces do not support generic parameterized methods, as the compiler says.
There is no workaround because it’s a fundamental limitation. Parameterized methods in classes are implemented by adding one method per instantiation to the class. That works for classes since they are concrete, but is not viable for interfaces. That’s because interfaces are a table of functions and the size of that table cannot vary depending on which generic method instantiations happen to be present elsewhere in the code. For similar reasons, generic methods cannot be virtual or dynamic.
…
In any case, it’s not possible. One option is to use a class instead. I agree that this is a bind.
If you want to do it in an interface, the best you can do is:
function CastAs(const IID: TGUID): IInterface;
But you’d have to call it like this:
MyIntf := ProxyIntf.CastAs(IMyIntf) as IMyIntf;
which feels somewhat foul.
Choose your poison!
In the background, for every distinct use of generic method parameters, the compiler generates an overloaded concrete version of the method. That is possible for classes and records, but not for interfaces.
In practice, I either go for the last option, or have the interface expose a record or class type that can have the required generic method (so the compiler can generate the overloads at run-time).
All options feel somewhat ugly, so I like the comment by [WayBack] Jason:
Which leads to Code Complete
[WayBack] What are the key points of Code Complete? – Software Engineering Stack Exchange answer by [WayBack] limist:
Code Complete is about software craftsmanship; it is an advanced-beginner/intermediate-level book, written for the working programmer, but it would still be very useful to someone who’s been programming for at least a year.
Thus the key points of Code Complete (2nd ed.) are nicely summarized in its Chapter 34, Themes in Software Craftsmanship. As paraphrased from my notes:
- Conquer Complexity: reduce the cognitive load on your mind via discipline, conventions, and abstraction.
- Pick Your Process: be conscious of quality from start (requirements) to finish (deployment) and beyond (maintenance).
- Write Programs for People First, Computers Second: code readability is hugely important for comprehensibility, review-ability, error-rate, error-correction, modifiability, and the consequent development time and quality.
- Program into Your Language, Not in it: think of the What? and Why? before the How?
- Focus Your Attention with the Help of Conventions: conventions manage complexity by providing structure where it’s needed, so that the ultimate resource – your attention – can be effectively used.
- Program in Terms of the Problem Domain: work at the highest level of abstraction possible; top-level code should describe the problem being solved. Distinguish OS level, programming language level, low-level implementation structures, low-level problem domain terms, and finally, high-level problem-domain terms that would make total sense to the (non-coder) user.
- Watch for Falling Rocks: as programming merges art and science, good judgement is vital, including heeding warning signs.
- Iterate, Repeatedly, Again and Again: iterate requirements, design, estimates, code, code tuning.
- Thou Shalt Render Software and Religion Asunder: be eclectic and willing to experiment. Don’t be an inflexible zealot, it precludes curiosity and learning. Go beyond having just a hammer in your toolbox.
But the most important take-aways are in Chapter 33, Personal Character: once you consciously seek to improve as a coder, you can and will. The fastest way to do so is to take on the the attitudes of master coders(humility, curiosity, intellectual honesty, discipline, creativity), while also practicing their habits (many good habits are listed in the book, e.g. choosing good variable/value names).
Also, the book makes clear that the gap between average and excellent in software is immense; that fact alone should drive the conscientious coder to better himself.
That’s the short of it; the long version is in the book. :) I can also send you my not-so-long, not-so-short notes if you want more details. But the book is certainly money and time well-spent, even if the writing style is tiresome at times.
Beyond Code Complete, I’d highly recommend The Pragmatic Programmer. It’s for intermediate-level programmers, nicely-written and a great mix of high, medium, and low-level advice.
There are more limitations on generics in Delphi
The documentation on limitations has not changed much since Delphi 2009.
Delphi 2009
[WayBack] Overview of Generics: Platform Requirements and Differences
Generics are supported by the Delphi for Win32 compiler.
Runtime type identification (RTTI)
In Win32, generics and methods do not have RTTI, but instantiated types do have RTTI. An instantiated type is the combination of a generic with a set of parameters.
Interface GUID
In Win32, an instantiated interface type does not have an interface GUID.
Parameterized method in interface
A parameterized method (method declared with type parameters) cannot be declared in an interface.
Instantiation timing
Instantiation is processed by the compiler. All instantiated objects are emitted into .obj files.
Dynamic instantiation
Dynamic instantiation at runtime is not supported.
Interface constraints
The Win32 interface is not a “light” interface. This means all type parameters with interface constraints always support the COM IUnknown methods _AddRef, _Release and QueryInterface or inherit from TInterfacedObject. Record types cannot specify an interface constraint parameter.
Delphi 10.3 Rio
[WayBack] Overview of Generics – RAD Studio: Platform Requirements and Differences
Generics are supported by the Delphi compilers.
Run-time type identification
In Win32, generics and methods do not have run-time type information (RTTI), but instantiated types do have RTTI. An instantiated type is the combination of a generic with a set of parameters. The RTTI for methods of a class is a subset of the RTTI for that class as a whole. If a non-generic class has a generic method, that method will not be included in the RTTI generated for the class because generics are instantiated at compile time, not at run time.
Interface GUID
In Win32, an instantiated interface type does not have an interface GUID.
Parameterized method in interface
A parameterized method (method declared with type parameters) cannot be declared in an interface.
Instantiation timing
Generic types are instantiated at compile time and emitted into executables and relocatable files. Instance variables of a generic type are instantiated at run time for classes and at compile time for generic records. The RTTI for generic classes is only generated when the classes are instantiated. RTTI for instantiated classes follows just as for non-generic classes. If the generic class has a generic method, then the instantiated generic class will not have RTTI for that generic method.
Dynamic instantiation
Dynamic instantiation at run time is not supported.
Interface constraints
The Win32 interface is not a “light” interface. This means all type parameters with interface constraints always support the COM IUnknown methods _AddRef, _Release, and QueryInterface or inherit from TInterfacedObject. Record types cannot specify an interface constraint parameter.
–jeroen
The Wiert Corner - irregular stream of stuff 