Тут фишка в том, что когда начинаешь переписывать, - однозначно теряешь... т.е. как минимум дублируешь уже существующий функционал, отказаться от которого не возможно... и, еще есть такой момент - не знаешь с какой стороны браться... т.е. например, сейчас я потрачу день (хорошо если) переписывая Tree, но, первая мысль будет ведь отнаследовать его от ListBase. Но врезультате скорее всего выяснится, что ListBase тоже надо переписывать... вобщем, я к тому, что слухи о том, что переписывание займет один день сильно преувеличены
Я пробовал и сам Tree писать, даже несколько раз, к сожалению похвастаться особо нечем, единственное, в чем уверен - это больше чем на день работы по-всякому.
Добавлено через 18 минут
Ромастый:
Ну так об чем жеж речь. Это возможно сделать средствами имеющимися в наличие. Доступ к свойству даже быстрее доступа к элементу массива - на этом и основан FastList в HaXe. У Adobe есть Alchemy, которая помимо всяких мега интересных и непонятных фишек по работе с памятью и т.п. может просто генерить ABC "на заказ". Тот же FastList это заготовка на уровне байткода, куда при компиляции доставляются нужные типы... Ну ничегошеньки не мешало Adobe сделать то же самое, запаковать в SWC collections.swc и положить в sdk/frameworks/libs *рядышком с generics.swc*
Естественно, для вью такой коллекции не хватило бы, потому что нужно еще и события диспатчить, но, опять же, никто Adobe не запрещал разработать это так, чтобы классы из collections.swc можно было наследовать - как бы это же и есть задача фреймворка... Фреймворку, кажеться, на днях 6 лет было... за это время можно было и не такое сделать...
EDIT:
Кстати, последний камень в огород Флексового компайлера:
Код:
//TODO PERFORMANCE: A lot of unnecessary recopying and buffering here
try
{
int result = compile(incremental);
...
}
И не думайте, это не фейк! Это из сорцев MXMLC.