Чем так плох Flex?

[wvxvw]

ОК... коллекции, и почему они не должны (не обязаны) быть во flash.collections.*. Если вы посмотрите на Java / C# - коллекции тоже не являются частью языка, а частями фреймворков, EE / SE - в Java или .NET соответственно. Просто в этих языках все привыкли к тому, что вендоры пишут низкоуровневые фишки оставляя реализацию програм уже самим пользователям фреймворка, и грань между тем, где заканчивается сам язык, а где начинаются библиотеки немного размыта. Во флексе это возможно было сделать точно так же, но из необъяснимых стратегических соображений это не было сделано.
ArrayCollection - это просто классика жанра в этом отношении.
Итак, для тех кто не совсем в курсе событий. ArrayCollection наследуется от ListCollectionView (единственной коллекции существующей во фреймворке - все остальные, это ее потомки в том или ином виде). Все, что она добавляет поверх ListCollectionView - это сериализацию в... Array! А теперь рассмотрим пошагово зачем это нужно.
Мы тут обойдем стороной спор о том плохо ли хорошо ли ORM, мы просто предположим, что мы души не чаим в ORM и поэтому мы хотим сериализовать ArrayCollection на сервере и отправить ее уже в готовом виде клиенту.
Типичная реализация фейк-класса нужного для сериализации ArrayCollection - отнаследоваться от ArrayObject (PHP) и ничего кроме этого не добавлять / не убирать, т.е. просто создать ArrayObject2 - полную копию ArrayObject. Оп-па - выстрел в пятку! Ну ладно, можно это чудо запихать в секретную директорию и не показывать пэхапэшникам от стыда подальше. Дальше, получили мы это чудо на клиенте - оп-па, и снова пальцы в двери, это ж весь датапровайдер надо поменять - все ссылки на него порушить и т.д. - прям плакать хочется, это ж сколько работы пропало. В итоге, почесав репу, удаляем PHP фейк, посылаем из сервиса массив, ресетим соурс на клиенте и радуемся жизни - и вот он момент истины! - мы опять открываем сорцы ArrayCollection и понимаем, что ту единственную функцию, которую она добавила к своему родителю мы как больше всего и не хотим использовать! А все потому, что кроме всего остального присутствует неразбериха в названиях ArrayCollection ни разу никакая не collection, это обертка, view, ее вообще протовопоказано сериализовать!
Дальше идем читаем блоги посвященные Флексу и тихо радуемся жизни

Что до UIComponent и life cycle - если вам нужна совместимость с не-фреймворковским кодом, даже рассматривать этот вариант смысла нет. Опять же, идея цикла компонентов не новая, она просто очень плохо скопирована со старших братьев - WPF / SWing ну и, в лучших традициях, со своими изюминками - типа "внезапно" создать два экземпляра вместо одного, или так же "внезапно" забыть вызвать какой-нибудь из методов, или "внезапно" у всех событий испускаемых этими компонентами будет по 2 инстанса (а че, жалко чтоли?) да еще и capture фаза (а чеб нам его стейджу или руту не задиспатчить, чтоб он там не расслаблялся?). Хуже всего то, что последнее вовсю эксплуатируется в MATE / SWIZ, и когда обнаружилось, нашлись поборники этих библиотек, которые уговорили это не менять мотивируя тем, что на их библиотеки это плохо повлияет, а остальные все равно не догадаются.
Еще из любимых внезапностей флекса - это уйти в бесконечную рекурсию валидаций, особенно часто случается со скроллерами, когда они то появляются, то исчезают нагревая ЦПЮ

Биндинг - это из серии "объять необъятное". Т.е. он по определению не может работать хорошо ни в каком виде никогда, можно долго замыливать глаза, дописывать десятки try-catch, но, в конце концов - облом. Ну вот так вот устроен язык, что нельзя в нем реализовать эту фичу, нужен либо другой язык, либо отказаться от затеи, третий путь по определению ущербен.

А вообще, все это беллетристика, потому что, не будь этого убожества, не было бы и притока новых программистов в AS3, и даже и тех куцых разработок, которые есть сейчас - тоже не было бы...

[r_r_f_r]

wvxvw, у старших братьев ЕСТЬ ШАБЛОНЫ, и у них реализовать на уровне языка нормальные контейнеры - можно, у нас - нет, у нас есть только не типизируемое ***** под названием прокси, если какие-то компоненты наровят наклонировать вашу коллекцию и это сильно сказывается на производительности - его можно переписать и долго не думать, при этом перепись с копированием нормального кода занимает денёк, да конечно, они могли написать ..., но они этого не сделали, вот писал этот компонент человек с больной головой, что тут поделать, главное что кастет написан на нормальную голову.

"идея цикла компонентов не новая", конечно не новая, и она не только в старших братьях, она везде, и даже в паттернах, под названием компоновщик.

[Ромастый]

Если вы посмотрите на Java / C# - коллекции тоже не являются частью языка, а частями фреймворков, EE / SE - в Java или .NET соответственно.

Ну это уже удар ниже пояса... Как бы разработчики под java и .net могут быть спокойны, что написанный ими код исполняется с той же скоростью, что и встроенный в язык функционал... Flash, увы, похвастаться этим не может, поэтому единственным выходом была бы поддержка коллекций на нативном уровне, аналогично массиву. Так что коллекции - беда не столько флекса, сколько флэша. А пример с ArrayCollection - как раз тот случай, когда лучше написать свое, чем пользоваться предоставляемым фреймворком. Так у нас есть свои реализации IList и ICollectionView, которые отлично работают и пихаются в качестве датаПровайдера во флексовые компоненты, и которые представляют собой реализацию джавовских List, Set и Map. Кроме того они поддерживают сериализацию/десериализация (правда у на она своя, не AMF. Как скажет etc - с блэкджеком и шлюхами). Единственный недостаток - скорость по сравнению с Array. Так binarySearch + splice в Array забарывает RBTree, хотя в той же java это одна из наиболее быстрых коллекций по работе с упорядоченными данными.

Насчет UIComponent я уже высказался. Это отправная точка - юзать или не юзать флекс. Если нужна большая скорость или совместимость с pure AS3 - флекс идет лесом. Не нужны - худо ли или нет, но он со своими обязанностями справляется, можно поюзать.

Так что пока нет альтернатив, или etc не выложит свой мегазамечательный фреймворк в открытый доступ - надо или пользоваться тем, что есть (понятно, с применением головы и по-возможности прямых рук) или писать свое. Что не всегда целесообразно или, как сказал Нуран - рентабельно, в контексте той или иной задачи.

[lowka]

Сообщение от wvxvw

А вообще, все это беллетристика, потому что, не будь этого убожества, не было бы и притока новых программистов в AS3, и даже и тех куцых разработок, которые есть сейчас - тоже не было бы...

Они идут не благодаря наличию кривого flex framework, а из-за того, что flash выбил для себя место под солнцем. Думаете, что они прям и мечтают его переписывать? Или же обилие багов и косяков мистическим образом действуют на программистов, что они как мотыльки, летящие на пламя, сгорают, чтобы покодить, используя кривую библиотеку? Увольте. Никому никогда не было и не будет такое счастье нужно. Так что не из-за наличия сего "убожества", а даже вопреки.

[wvxvw]

Тут фишка в том, что когда начинаешь переписывать, - однозначно теряешь... т.е. как минимум дублируешь уже существующий функционал, отказаться от которого не возможно... и, еще есть такой момент - не знаешь с какой стороны браться... т.е. например, сейчас я потрачу день (хорошо если) переписывая 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.