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

[Iv]

Для того, чтобы решить что делать дальше, откройте в FDT панель Problems и отсортируйте по столбцу Resource.
Здесь мы видим два типа ошибок:
Local Variable is never used (локальная переменная никогда не используется)
Untyped member access (нетипизированный доступ к членам)

Первая ошибка встречается лишь однажды: двойным кликом по соответствующей строке в панели Problems переходим на строку с ошибкой в коде и удаляем ее.
В итоге у нас останутся только ошибки нетипизированного доступа.

Просмотрев код видим, что ошибки вызваны нетипизированными обращениями к переменным объектов fill, stroke, firstP, lastP, lastC. Первые два объявлены как переменные класса, остальные как локальные переменные метода makeDrawCmds.

Начнем с локальных переменных. Судя по их использованию в коде, они могут быть типизированы как Point. Попробуем заменить тип на Point в их объявлении.
После замены типов и сохранения документа количество ошибок резко уменьшилось и изменился их тип на "You can not assign an 'Object' to a 'Point'".
Заменим, вот пример замены:
Было:

firstP = lastP = {x:Number(svgCmds[j]), y:Number(svgCmds[j + 1])};

Стало:

firstP = lastP = new Point(Number(svgCmds[j]), Number(svgCmds[j + 1]));

Чтобы ускорить этот процесс я воспользовался поиском и заменой, шаг за шагом заменяя строку "{x:" на "new Point(", внимательно следя за тем, чтобы не заменить эту строку там, где это не следовало бы делать. А именно в вызовах Math2.getQuadBez_RP(...).
Затем, кликая по образовавшимся у скроллера красным меткам ошибок, я переходил на очередную строку с ошибкой и заменял закрывающую фигурную скобку на обычную и удалял "y:".

В итоге, количество ошибок типизации в классе снизилось до шести. Все они - обращения к переменным объектов fill и stroke.
В отличие от предыдущего шага, у этих объектов отсутствует соответствие в родных классах Flash и нам потребуется создать собственные.

Сразу за самой последней закрывающей фигурной скобкой документа создадим внутренние классы.
Затем зададим им публичные поля, одноименные с теми, доступ к которым осуществляется из объектов fill и stroke. Добавим в конструкторы соответствующие аргументы.
Вот, что у меня получилось:

internal class Fill {
 
	public var color:uint;
	public var alpha:Number;
 
	public function Fill(color:uint, alpha:Number) {
		initInstance(color, alpha);
	}
 
	private function initInstance(color : uint, alpha : Number) : void {
		this.color = color;
		this.alpha = alpha;
	}
}
 
internal class Stroke {
 
	public var color:uint;
	public var alpha:Number;
	public var width:Number;
 
	public function Stroke(color:uint, alpha:Number, width:Number) {
		initInstance(color, alpha, width);
	}
 
	private function initInstance(color : uint, alpha : Number, width : Number) : void {
		this.color = color;
		this.alpha = alpha;
		this.width = width;
	}
}

Классы подготовлены, заменяем типы в объявлениях переменных fill и stroke на вновь созданные.

private var fill : Fill;
private var stroke : Stroke;

После этого список в панели Problems изменяется и вместо ошибок отсутствия типа мы получаем "You can not assign an 'Object' to an 'Stroke'".
Здесь способ ускорения процесса правки несколько иной. Перейдя на начало документа, используем сочетание клавиш CTRL+1. FDT - умница, он хоть и не может решить всех проблем, но он предлагает добавить кастинг соответствующего типа. Соглашаемся, после чего добавляем ключевое слово new и удаляем имена полей и фигурные скобки.
было:

fill = {color:0, alpha:0};

стало после кастинга:

fill = Fill({color:0, alpha:0});

мы исправили:

fill = new Fill(0, 0);

Проделывая те же манипуляции с объектом stroke, обязательно нужно обратить внимание на то, что последовательность, в которой расположены переменные в старом объекте stroke, не соответствует последовательности аргументов и мы должны поменять местами два последних аргумента.

Закончив, выделим двойным кликом Fill проверяем, везде ли расставлено ключевое слово new. То же самое проделываем со Stroke.

В результате наших действий, в классе PathToArray не должно остаться ни одной подсвечивающейся ошибки.

Тестируем, убеждаемся в том, что Flash-компилятор не ругается, а изображение рисуется.

Итоговый класс аттачу к этому посту.