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.

Iniziate con l’esempio TreeMap.ts collegato e confrontate i suoi overload ripetuti del costruttore e i suoi rami con la sintassi using proposta. Esaminate quindi come TypeScript rappresenta i costruttori ereditati e gli insiemi di overload prima di definire la semantica e i requisiti di compatibilità della funzionalità. Il lavoro è completo quando la sintassi e il comportamento degli overload ereditati sono specificati e convalidati dai test del compilatore pertinenti.