Портируем, рефакторим, оптимизируем

[Iv]

А теперь можно заняться удалением теперь уже ненужных аргументов.

Заменим создание объекта source на присвоение ему this:

const source:CubicBezierSVG = this;

И тут же тестируем и видим, что происходит переполнение стека. Причина совсем рядом: рекурсивный вызов метода.
До тех пор, пока использовались аргументы, в методе создавались новые объекты CubicBezierSVG. А как только перешли на использование this наша невнимательность выползла наружу: мы не добавили объекты, от имени которых рекурсивно вызывается метод getQuadBez_RP.
Исправим.
Для начала откатимся назад до рабочего состояния:

const source:CubicBezierSVG = new CubicBezierSVG(start, startControl, endControl, end);

Вот тут-то и проявляется прелесть исправления кода короткими шагами.
Протеституем, убедимся, что всё работает.

Вот участок кода, который требует вмешательства:

getQuadBez_RP (source.start, firstHalf.startControl, firstHalf.endControl, firstHalf.end, k, qcurves);
getQuadBez_RP(secondHalf.start, secondHalf.startControl, secondHalf.endControl, source.end, k, qcurves);

Мы видим, что аргументы каждого вызова берутся из разных объектов. Для вызова в основном используются данные половинок кривой sourceBezier, а отличаются от остальных в первом случае - первый аргумент, а во втором случае четвертый и оба берут данные из совсем другого объекта - source. Но такие ли разные объект source и sourceBezier? Мы видим, что вовсе нет. Объект sourceBezier создан полностью из данных объекта source. Так может попробовать удалить sourceBezier и использовать source вместо него?

В этот момент мы должны остановиться и сказать себе: это не рефакторинг. Это действия по изменению логики приложения. К таким действиям мы должны подходить с совсем другими правилами.