Add a mechanism to copy another function/method's overload set

Problem

Outline

When I make a new sub-class from a parent-class who has multiple overloaded constructors (or some methods), I've to re-write the definition (header) of each function and re-write branch-condition again. It's very annoying and tiresome work for me.

With an example

https://github.com/samchon/stl/blob/master/ts/src/std/TreeMap.ts#L72-L177

class TreeMap<Key, T> extends base.UniqueMap<Key, T>
{
    // THOSE DEFINITIONS ARE REPEATED IN EVERY SUB-CLASSES
    constructor();
    constructor(compare: (left: Key, right: Key) => boolean);
    constructor(array: Array<Pair<Key, T>>);
    constructor(array: Array<Pair<Key, T>>, compare: (left: Key, right: Key) => boolean);
    constructor(array: Array<[Key, T]>);
    constructor(array: Array<[Key, T]>, compare: (left: Key, right: Key) => boolean);
    constructor(container: base.MapContainer<Key, T>);
    constructor(container: base.MapContainer<Key, T>, compare: (left: Key, right: Key) => boolean);
    constructor(begin: MapIterator<Key, T>, end: MapIterator<Key, T>);
    constructor(begin: MapIterator<Key, T>, end: MapIterator<Key, T>, compare: (left: Key, right: Key) => boolean);

    constructor(...args: any[])
    {
        // THOSE BRANCH CONDITIONS ARE ALSO REPEATED TOO
        // condition statements identifying type of arguments
        /*IF 
        ELSE IF
        ELSE IF
       ...*/
    }
}

In the link, you can see the TreeMap class inherited from base.UniqueMap. Of course, you also can see that the constructors and branch-condition codes have to be re-written.

Those idiot codes are repeated in every sub-classes in my fucking project.

Solution

Suggest: using statement

Those're very annoying and inefficient job for development. So I want to suggest a notation can reduce such in-efficient works.

In C++, fetching all overloaded methods from parent can be implemented by just a line.
With using statement. using Parent::methodName;

template <class T>
class URLVariables : public std::map<std::string, T>
{
private:
    typedef std::map<std::string, T> super;

public:
    // ALL THE CONSTRUCTORS + CUSTOM ONE
    using super::map; // [using super::super] is also possible

    /* -- THOSE CAN BE OMITTED BY USING STATEMENT --
    URLVariables();
    URLVariables(const super &);
    URLVariables(super &&);
    URLVariables(const std::initializer_list<std::pair<std::string, T>>> &);
    template <InputIterator> URLVariables(InputIterator first, InputIterator last);
    */

    URLVariables(const std::string &);

    // ALL THE COUNT METHODS + CUSTOM ONE
    using super::count;
    bool count(const std::string_view &) const;
    bool count(const ByteArray &) const;
}

If the using statement is adopted in TypeScript, codes will be much precise like below. Isn't it much precise than codes of the top?

class TreeMap<Key, T> extends base.UniqueMap<Key, T>
{
    // THE USING STATEMENT
    using super.constructor;

    // THOSE RE-DEFINITIONS ARE OMITTED BY THE USING STATEMENT
    /*constructor();
    constructor(compare: (left: Key, right: Key) => boolean);
    constructor(array: Array<Pair<Key, T>>);
    constructor(array: Array<Pair<Key, T>>, compare: (left: Key, right: Key) => boolean);
    constructor(array: Array<[Key, T]>);
    constructor(array: Array<[Key, T]>, compare: (left: Key, right: Key) => boolean);
    constructor(container: base.MapContainer<Key, T>);
    constructor(container: base.MapContainer<Key, T>, compare: (left: Key, right: Key) => boolean);
    constructor(begin: MapIterator<Key, T>, end: MapIterator<Key, T>);
    constructor(begin: MapIterator<Key, T>, end: MapIterator<Key, T>, compare: (left: Key, right: Key) => boolean);*/

    constructor(...args: any[])
    {
        // CALLING SUPER CONSTRUCTORS' RE DONE BY
        super(...args);
    }
}

I'm waiting for your opinion and eagerly looking forward to the enhancement.

Beginnen Sie mit dem verknüpften TreeMap.ts-Beispiel und vergleichen Sie dessen wiederholte Konstruktorüberladungen und Verzweigungen mit der vorgeschlagenen using-Syntax. Untersuchen Sie anschließend, wie TypeScript geerbte Konstruktoren und Überladungssätze darstellt, bevor Sie die Semantik und Kompatibilitätsanforderungen des Features festlegen. Als abgeschlossen gilt die Arbeit, wenn die Syntax und das Verhalten geerbter Überladungen spezifiziert und durch relevante Compiler-Tests validiert sind.