Further to the ranges in generics discussion....... more on generics

There is always a way to do that using an abstract class. The things of interest creating the idea are:

1. Imagine a short hand syntax for abstract classes:

Generic classAbs<T> = class(TObject)
	Class generic variable: TObject;
End;
abClass = specialize classAbs<abstract>;
// This allows a short hand, and

2. Some possible crazy inheritance:

Generic classAbs<T,Q> = class(Q)
	Class generic variable: TObject;
End;
abClass = specialize classAbs<Integer, abstract>;
// which allows a form of polymorphic inheritance similar to interfaces, but short hand for interface variables.

3. Some code optimization for less cache thrashing

Class generic procedure classAbs.doSomething(T);
//generic procedure x.y(T); this also
Begin
	// enforce no usage of field and methods on T, such as T.specificToClass()
       // allows same piece of code to be used for all types of same sizeof()
       // so less code to fill the L1 instruction cache, and the L2 cache is less burdened
       // of course this speed and code size optimization could be detected without this
       // but enforcing it could always be an option.
End;

4. Compile time virtual kind of resolution

// As an abstract class would have many virtual abstract methods there would be a pointer indirection from the VMT.
// Any generic procedure or method could, if not virtual, be compiled in and so not need a virtual specifier.

Am Mo., 3. Dez. 2018, 15:16 hat Simon Jackson
geschrieben:

Further to the ranges in generics discussion....... more on generics

I've already mentioned my reasons against that. So throwing around strange syntax extensions does not ,
Sven