Parameterized next pool impossible for class hierarchy of pooled objects?

Question

With regards to the cpp tag. This pattern is relevant generally to parameterization, and can be implemented in C++ with templates. My primary query is whether this is a logically solveable pattern (which I believe it isn't as specified) in C++ and the AVM2, with a preference to solving it with haxe. The particular code sample and query in general, written in Haxe, compiles to the relevant C++ target in a logically identical way.

I am inquiring if there is fix to this pattern with:

1. Parameterization logic
2. There is some other way to maintain the link of free objects other than a next property close to the optimal implementation of a direct typed member access as facilitated by said next property (eg avoiding a reflective/switch call for access to the next member)
3. I am aware there are other pooling implementations, that is not what I am asking.

Question:

It would appear that there is no way to define a parameterized pool for a Class that extends from a Class that itself is pooled because the subclass cannot conform to Poolable_i interface because it cannot redefine the next property. Is this a valid conclusion?

Ie: the a Pool_pointer<Destination> cannot exist because Destination cannot conform to any useful constraint specified in Pool_pointer<Destination>

For instance:

Poolable_i<T> is a base that hase a single property next:T
Point3d implements Poolable_i<Point3d>
Destination extends Point3d {
    public var time:Time;
}

This is also presuming that you do not wish to use a base class that itself is parameterized, eg Point3d_base<T:{Poolable_i<T>,Point3d_base}> because one may require a hierarchy with a depth greater than 1.

Of course this can be solved in multiple ways with preprocessing as I intend to do. I am just curious if I am missing something with regards to the impossibility of said templating implementation.

package test.shared;
class Pool_pointer<T:Poolable_i<T>> implements Pool_i<T> {
    public var free:T;
    public function new() {
    }
    public function destroy():Void {
    }
    public inline function get():T {
        var r:T=null;
        if(free==null) {
            r=new T();
        } else {
            r=free;
            free=r.next;
        }
        return r;
    }
    public inline function put(v:T):Void {
        v.next=free;
        free=v;
    }
}

Answer 1

The solution is to parameterize the entire hierarchy with regards to functionality declarations and create typedefs/specific Classes for concrete implementations.

Destination_base<NextT> -> Destination extends Destination_base<Destination>
^
|
Point3d_base<NextT> -> Point3d extends Point3d_base<Point3d>

Implementation hierarchy is parameterized. Ugh. Love thy preprocessing.